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FOREWORD 


Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management  of  the  Federal  Telecommunication 
Standards  Program  which  is  an  element  of  the  overall  GSA  Federal  Standardization 
Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the  Federal 
Telecommunication  Standards  Committee,  identifies,  develops,  and  coordinates 
proposed  Federal  Standards  which  either  contribute  to  the  interoperability  of 
functionally  similar  Federal  telecommunication  systems  or  to  the  achievement  of  a 
compatible  md  efficient  interface  between  computer  aid  telecommunication 
systems.  In  developing  and  coordinating  these  standards  a considerable  amount  of 
effort  is  expended  in  initiating  and  pursuing  joint  standards  development  efforts 
with  appropriate  technical  committees  of  the  Electronic  Industries  Association,  the 
American  National  Standards  Institute,  the  International  Organization  for 
Standardization,  and  the  International  Telegraph  and  Telephone  Consultative 
Committee  of  the  International  Telecommunication  Union.  This  Technical 
Information  Bidletin  presents  an  overview  of  an  effort  which  is  contributing  to  the 
development  of  compatible  Federal,  national,  and  international  standards  in  the 
area  of  data  communication  interface  standards.  It  has  been  prepared  to  inform 
interested  Federal  activities  of  the  progress  of  these  efforts.  Any  comments, 
inputs,  or  statements  of  requirements  which  could  assist  in  the  advancement  of  this 
work  are  welcome  and  should  be  addressed  to: 
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BACKGROUND 


Intense  activity  over  the  past  several  years  is  leading 
to  a new  generation  of  interface  standards  for  the  emerging 
public  data  networks  being  implemented  in  numerous  countries 
around  the  world.  These  new  data  networks  will  offer  a 
variety  of  services  including  circuit-switched,  packet-switched, 
and  leased  line  to  support  the  rapidly  expanding  computer 
and  digital  communications  requirements. 

Packet-switching  technology  is  presently  dominating  current 
implementations  as  exemplified  by  the  proposed  AT&T  Advanced 
Communications  Service  (ACS),  Telenet,  and  Tymnet  in  the 
USA.  Active  implementation  are  also  underway  in  Canada, 

Japan,  and  many  European  countries. 

The  International  Telegraph  and  Telephone  Consultative  Committee 
(CCITT)  has  lead  the  way  in  early  standardization  of  interface 
protocols  to  encourage  timely  implementations  on  a worldwide 
basis.  In  early  1976,  the  draft  proposal  was  introduced 
into  CCITT  for  a virtual  circuit  packet-switched  service. 
Agreement  was  reached  in  May  1976,  and  in  September  1976, 
the  proposal  was  approved  as  Recommendation  X.25  by  the 
CCITT  Sixth  Plenary  Assembly. 

The  unprecedented  speed  at  which  X.25  was  adopted  left  serious 
questions  as  to  the  technical  soundness  of  the  standard. 

There  were  many  uncompleted  items  left  "for  further  study," 
and  there  were  numerous  ambiguities.  The  fact  that  inter- 
national agreement  was  received,  however,  was  sufficient 
for  a number  of  technologically  advanced  countries  to  make 
large  investments  in  implementing  new  public  data  networks 
using  this  packet -switching  technology.  As  a result  X.25 
has  now  proved  to  be  an  effective  guideline  for  the  new 
generation  of  designs. 

X.25  describes  the  interface  and  procedures  for  a virtual 
circuit  type  of  packet-switched  service  and  it  is  defined 
in  three  architectural  independent  levels  as  follows: 

Level  1 - The  physical,  electrical,  functional  and  procedural 
characteristics  to  establish,  maintain  and 
disconnect  the  physical  link  between  the  DTE 
and  the  DCE. 

Level  2 - The  link  access  procedure  for  data  interchange 
across  the  link  between  the  DTE  and  the  DCE. 


The  Fast  Select  provision  allows  a full  128  octets  of  user 
data  to  be  exchanged  during  the  call  set-up,  and  possibly 
clearing,  procedures  for  a virtual  call.  This  would  greatly 
increase  the  efficiency  of  operation  for  many  transaction 
applications. 

The  datagram  operation  has  been  one  of  considerable  controversy 
in  CCITT.  Determined  efforts  from  the  USA,  however,  have 
now  resulted  in  general  acceptance.  Datagrams  are  self- 
contained  packets  with  a maximum  of  128  octets  of  user  data, 
and  each  datagram  has  sufficient  address  information  to 
be  routed  to  its  destinations.  No  call  set-up  procedures 
are  necessary.  Datagram  operation  proves  more  effective 
for  efficient  fast  transjx^rt  of  small  units  of  data  and 
provides  greater  flexibility  for  a number  of  network  and 
user  applications. 

It  should  not  be  considered  that  the  different  modes  of 
packet  operation  are  competitive.  They  are,  in  fact,  comple- 
mentary in  most  effectively  covering  a large  portion  of 
applications.  Another  mode  of  operation  to  be  studied  in 
the  future  is  a message  service  which  will  further  complement 
the  others. 

When  the  work  on  the  revised  X.25,  including  the  Fast  Select 
and  Datagram  provision,  is  completed  and  approved  by  CCITT 
in  1980,  it  is  expected  to  be  adopted  as  a Federal  Standard. 

Each  level  of  X.25,  earlier  defined,  is  expected  to  be  a 

separate  standard.  At  level  1,  proposed  Federal  Standard 

1031,  which  adopts  EIA  RS-449,  is  expected  to  be  applied 

initially.  Then  proposed  Federal  Standard  1040,  which  adopts 

the  physical,  functional,  and  mechanical  characteristics 

of  X.21  will  evolve  into  use  as  industry  makes  equipment 

available.  At  level  2,  Federal  Standard  1003  will  apply 

using  the  designated  subset  that  is  compatible  with  X.25 

LAP  B.  Finally,  at  level  3,  another  Federal  Standard  will 

specify  the  network  control  at  the  packet  level  including 

the  Datagram  and  Fast  Select  provisions.  * 


The  Appendix  to  this  TIB  provides  the  current  working  draft 
of  the  basic  level  3 of  X.25  excluding  the  Fast  Select  and 
Datagram  provisions.  It  represents  the  work  that  has  been 
completed  through  November  1978.  Additional  revisions  will 
be  forthcoming  as  a result  of  further  Special  Rapporteur 
meetings  in  April  and  Autumn  1979. 

The  work  on  Fast  Select  and  Datagrams  is  now  progressing 
rapidly  under  the  CCITT  Special  Rapporteurs.  A draft  integrat- 
ing the  Datagram  provisions  into  the  X.25  test  is  issued 
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The  Fast  Select  provision  allows  a full  128  octets  of  user 
data  to  be  exchanged  during  the  call  set-up,  and  possibly 
clearing,  procedures  for  a virtual  call.  This  would  greatly 
increase  the  efficiency  of  operation  for  many  transaction 
applications. 

The  datagram  operation  has  been  one  of  considerable  controversy 
in  CCITT.  Determined  efforts  from  the  USA,  however,  have 
now  resulted  in  general  acceptance.  Datagrams  are  self- 
contained  packets  with  a maximum  of  128  octets  of  user  data, 
and  each  datagram  has  sufficient  address  information  to 
be  routed  to  its  destinations.  No  call  set-up  procedures 
are  necessary.  Datagram  operation  proves  more  effective 
for  efficient  fast  transport  of  small  units  of  data  and 
provides  greater  flexibility  for  a number  of  network  and 
user  applications. 

It  should  not  be  considered  that  the  different  modes  of 
packet  operation  are  competitive.  They  are,  in  fact,  comple- 
mentary in  most  effectively  covering  a large  portion  of 
applications.  Another  mode  of  operation  to  be  studied  in 
the  future  is  a message  service  which  will  further  complement 
the  others. 

When  the  work  on  the  revised  X.25,  including  the  Fast  Select 
and  Datagram  provision,  is  completed  and  approved  by  CCITT 
in  1980,  it  is  expected  to  be  adopted  as  a Federal  Standard. 
Each  level  of  X.25,  earlier  defined,  is  expected  to  be  a 
separate  standard.  At  level  1,  proposed  Federal  Standard 
1031,  which  adopts  EIA  RS-449,  is  expected  to  be  applied 
initially.  Then  proposed  Federal  Standard  1040,  which  adopts 
the  physical,  functional,  and  mechanical  characteristics 
of  X.21  will  evolve  into  use  as  industry  makes  equipment 
available.  At  level  2,  Federal  Standard  1003  will  apply 
using  the  designated  subset  that  is  compatible  with  X.25 
LAP  B.  Finally,  at  level  3,  another  Federal  Standard  will 
specify  the  network  control  at  the  packet  level  including 
the  Datagram  and  Fast  Select  provisions. 

The  Appendix  to  this  TIB  provides  the  current  working  draft 
of  the  basic  level  3 of  X.25  excluding  the  Fast  Select  and 
Datagram  provisions.  It  represents  the  work  that  has  been 
completed  through  November  1978.  Additional  revisions  will 
be  forthcoming  as  a result  of  further  Special  Rapporteur 
meetings  in  April  and  Autumn  1979. 

The  work  on  Fast  Select  and  Datagrams  is  now  progressing 
rapidly  under  the  CCITT  Special  Rapporteurs.  A draft  integrat- 
ing the  Datagram  provisions  into  the  X.25  test  is  issued 
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in  NCS  TIB  79-4J,^  After  the  April  1979  CCITT  meetings  of 
the  Special  Rapporteurs  the  Fast  Sele.-^t  text  is  also  expected 
to  be  available  and  will  be  issued  as  another  NCS-TIB. 

Every  effort  is  made  during  the  development  of  these  standards 
to  ensure  that  requirements  of  Federal  activities  are  thoroughly 
considered  in  the  work  of  CCITT  Study  Group  VII.  Accordingly, 
we  would  greatly  appreciate  any  input  your  agency  might 
care  to  make  to  the  further  development  of  X.25.  Such  input 
should  be  sent  to  the  NCS  office  identified  in  the  Foreword 
of  this  publication. 


3.  DESCRIPTION  OP  THE  PACKETLEVEL  DTE/DCE  INTERFACE  FOR 
VIRTUAL  CALL  AND  PERMANENT  VIRTOAL  CIRCDIT  FACILITIES 

jifga-n 

This  section  of  the  recommendation  relates  to  the  transfer  of 
packets  at  the  DTE/DCE  interface.  The  procedures  apply  to 
packets  which  are  successfully  transferred  across  the  DTE/DCE 
interface. 

Each  packet  to  be  transferred  across  the  DTE/DCE  interface  shall 
be  contained  within  the  link  level  information  field  which  will 
delimit  its  length,  and  only  one  packet  shall  be  contained  in 
the  information  field. 

NOTE;  Possible  insertion  of  more  than  one  packet  in  the  link 
level  information  field  is  for  further  study. 

To  enable  simultaneous  virtual  calls  and/or  permanent  virtual 
circuits,  logical  channels  are  used.  Each  virtual  call  or 
permanent  virtual  circuit  is  assigned  a logical  channel  group 
number  (less  than  or  equal  to  15)  and  a logical  channel  number 
(less  than  or  equal  to  255) . For  virtual  calls  a logical  chamnel 
group  number  and  a logical  channel  number  are  assigned  during 
the  call  set'up  phase.  For  permanent  virtual  circuits  a logical 
channel  group  number  and  a logical  channel  number  are  assigned 
in  agreement  with  the  Administration  at  the  time  of  subscription 
to  the  service.  The  range  of  logical  channels  used  for  virtual 
calls  is  agreed  with  the  Administration  at  the  time  of 
subscription  to  the  service. 

3.1  Procedures  for  Virtual  Calls 

Annex  1,  Figures  15/X.25,  16/X.25  and  17/X.25  show  the  state 
diagrams  which  give  a definition  of  events  at  the  packet  level 
DTE/DCE  interface  for  each  logical  channel  used  for  virtual 
calls. 

Annex  2 gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  1.  Details  of  the 
actions  which  should  be  taken  by  the  DTE  are  for  further  study. 

Packet  formats  are  given  in  section  4 of  this  Recommendation. 

3.1.1  Ready  State 

If  there  is  no  call  in  existence,  a logical  channel  is  in  the 
READY  State. 
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3.1.2  call. Request  Packet 


The  calling  DTE  shall  indicate  a call  request  by  transferring' 
a CALL  REQUEST  packet  across  the  DTE/DCE  interface.  The  logical 
channel  selected  by  the  DTE  is  then  in  the  DTE  NAITIN6  state 
(p2)  . The  CALL  REQUEST  packet  includes  the  called  DTE  address. 
The  calling  DTE  address  field  may  also  be  used. 

NOTE  1;  A DTE  address  may  be  a DTE  network  address,  an 

adsbreviated  address  or  any  other  DTE  identification 
agreed  for  a period  of  time  between  the  DTE  and  the 
DCE. 

NOTE  2;  The  CALL  REQUEST  packet  should  use  the  logical  channel 
in  the  READY  state  with  the  highest  number  in  the  range 
which  has  been  agreed  with  the  Administration.  Thus 
the  risk  of  call  collision  is  minimized. 


3.1.3  InsoBinq  Call  Packet 

The  DCE  will  indicate  that  there  is  an  incoming  call  by 
transferring  across  the  DTE/DCE  interface  an  INCOMING  CALL 
packet.  This  places  the  logical  channel  in  the  DCE  WAITING 
state  (p3)  (see  section  3.7)  . 

The  INCOMING  CALL  packet  will  use  the  logical  channel  in  the 
READY  state  with  the  lowest  number.  The  INCOMING  CALL  packet 
includes  the  calling  DTE  address.  The  called  DTE  address  field 
may  also  be  used. 

NOTE:  A DTE  address  may  be  a DTE  network  address,  an  abbreviated 
address  or  any  other  DTE  identification  agreed  for  a 
period  of  time  between  the  DTE  and  the  DCE. 

3.1.4  Call  Accepted  Packet 

The  call*^d  DTE  shall  indicate  its  acceptance  of  the  call  by 
transferring  across  the  DTE/DCE  interface  a CALL  ACCEPTED  packet 
specifying  the  same  logical  channel  as  that  of  the  INCOMING 
CALL  packet.  This  places  the  specified  logical  channel  in  the 
DATA  TRANSFER  State  (p4)  . 

If  the  called  DTE  does  not  accept  the  call  by  a CALL  ACCEPTED 
packet  or  does  not  reject  it  by  a CLEAR  REQUEST  packet  as 
described  in  section  3.1.7  within  a specified  time  limit,  the 
DCE  will  consider  it  as  a procedure  error  from  the  called  DTE 
and  will  clear  the  virtual  call  according  to  the  procedure 
described  in  section  3.1.6. 


- • - 


The  time  limit  is  network  dependent;  its  ra-ige  is  for  further 
study. 

3.1.5  Call  Connected  Packet 

The  receipt  of  a CALL  CONNECTED  packet  by  the  calling  DTE 
specifying  the  same  logical  channel  as  that  specified  in  the 
CALL  REQUEST  packet  indicates  that  the  call  has  been  accepted 
by  the  called  DTE  by  means  of  a CALL  ACCEPTED  packet.  This 
places  the  specified  logical  channel  in  the  DATA  TRANSFER  state 
(P**)  . 

3.1.6  Call  Collision 

Call  collision  occurs  when  a DTE  and  DCE  simultaneously  transfer 
a CALL  REQUEST  packet  and  an  INCOMING  CALL  packet  specifying 
the  same  logical  channel.  The  DCE  will  proceed  with  the  call 
request  and  cancel  the  incoming  call. 

3.1.7  Clearing  by  the  DTE 

At  any  time  the  DTE  may  indicate  clearing  by  transferring  across 
the  DTE/DCE  interface  a CLEAR  REQUEST  packet.  The  logical 
channel  is  then  in  the  DTE  CLEAR  REQUEST  state  (p6) . When  the 
DCE  is  prepared  to  free  the  logical  channel,  the  DCE  will 
transfer  across  the  DTE/DCE  interface  a DCE  CLEAR  CONFIRMATION 
packet  specifying  the  logical  channel.  The  logical  channel  is 
now  in  the  READY  state  (pi) . 

The  DCE  CLEAR  CONFIRMATION  packet  can  only  be  interpreted 
universally  as  having  local  significance,  however  within  some 
Administration's  networks  clear  confirmation  may  have  end  to 
end  significance.  In  all  cases  the  time  spent  in  the  DTE  CLEAR 
REQUEST  state  (p6)  will  not  exceed  a network  dependent  limit. 
This  limit  will  typically  be  lower  than  3 minutes. 

It  is  possible  that  subsequent  to  transferring  a CLEAR  REQUEST 
packet  the  DTE  will  receive  other  types  of  packets,  dependent 
on  the  state  of  the  logical  channel,  before  receiving  a DCE 
CLEAR  CONFIRMATION  packet. 

NOTE:  The  calling  DTE  may  abort  a call  by  clearing  it  before 
it  has  received  a CALL  CONNECTED  or  CLEAR  INDICATION 
packet. 

The  called  DTE  may  refuse  an  incoming  call  by  clearing  it  as 
described  in  this  section  rather  than  transmitting  a CALL 
ACCEPTED  packet  as  described  in  section  3.1.4. 


3.1.8  Clearing  by  the  DCE 


The  DCE  will  indicate' clearing  by  transferring  across  the  DTE/DCE 
interface  a CLEAR  INDICATION  packet.  The  logical  channel  is 
then  in  the  DCE  CLEAR  INDICATION  state  (p7) . The  DTE  shall 
respond  by  transferring  across  the  DTE/DCE  interface  a DTE  CLEAR 
confirmation  packet.  The  logical  channel  is  now  in  the  READY 
state  (pi)  (see  section  3.7). 

3.1.9  Clear  Collision 

Clear  collision  occurs  when  a DTE  and  a DCE  simultaneously 
transfer  a CLEAR  REQUEST  packet  and  a CLEAR  INDICATION  packet 
specifying  the  same  logical  channel.  The  DCE  will  consider 
that  the  clearing  is  completed  and  will  not  transfer  a DCE  CLEAR 
CONFIRMATION  packet. 

3.1.10  Unsuccessful  Call 

If  a call  cannot  be  established,  the  DCE  will  transfer  a CLEAR 
INDICATION  packet  specifying  the  logical  channel  indicated  in 
the  CALL  REQUEST  packet. 

3.1.11  Call  Progress  Signals 

The  DCE  will  be  capable  of  transferring  to  the  DTE  clearing 
call  progress  signals  as  specified  in  Recommendation  X.96. 

Clearing  call  progress  signals  will  be  carried  in  CLEAR 
INDICATION  packets  which  will  terminate  the  call  to  which  the 
packet  refers.  The  method  of  coding  CLEAR  INDICATION  packets 
containing  call  progress  signals  is  detailed  in  section  4. 

3.1.12  Data  Transfer  Phase 

The  procedures  for  the  control  of  packets  between  DTE  and  DCE 
while  in  the  DATA  TRANSFER  state  are  contained  in  section  3.3. 

3.2  Procedure  for  Permanent  Virtual  Circuits 

Annex  1,  Figures  15/X.25  and  17/X.25  show  the  state  diagrams 
which  give  a definition  of  events  at  the  packet  level  DTE/DCE 
interface  for  logical  channels  assigned  for  permanent  virtual 
circuits.  Annex  2,  Tables  11/X.25  and  12/X.25  give  details  of 
the  action  taken  by  the  DCE  on  receipt  of  packets  in  each  state 
shown  in  Annex  1,  Figures  15/X.25  and  17/X.25.  Details  of  the 
action  which  should  be  taken  by  the  DTE  are  for  further  study. 

For  permanent  virtual  circuits  there  is  no  call  set-up  or 
clearing. 


The  data  transfer  procedure  described  in  the  following  section 
applies  independently  to  each  logical  channel  existing  at  the 
DTE/DCE  interface. 

Normal  network  operation  dictates  that  user  data  in  data  packets 
and  interrupt  data  are  all  passed  transparently,  unaltered 
through  the  net%fork  in  the  case  of  packet  DTE  to  packet  DTE 
communications,  order  of  bits  in  data  packets  is  preserved. 

Packet  sequences  are  delivered  as  complete  packet  sequences. 

DTE  Diagnostic  codes  are  treated  as  described  in  Sections  4.2.3, 

4.4.3  and  4.5. 1. 

3.3.1  States  for  Data  Transfer  in  Virtual  Calls 

Data,  interrupt,  flow  control  and  reset  packets  may  be 
transmitted  and  received  by  a DTE  in  the  DATA  TRANSFER  state 
of  a logical  channel  at  the  DTE/DCE  interface.  In  this  state, 
the  flow  control  ani  rt.set  procedures  described  in  section  3.4 
apply  to  data  transmission  on  that  logical  channel  to  and  from 
the  DTE.  Data,  interrupt,  flow  control  and  reset  packets 
transmitted  by  a DTE  will  be  ignored  by  the  DCE  when  the  logical 
channel  is  in  the  DCE  CLEAR  INDICATION  state. 

When  a call  is  cleared,  data  and  interrupt  packets  may  be 
discarded  by  the  network.  (See  section  3.6).  | 

Data,  interrupt,  flow  control  and  reset  packets  that  are  in  the 
network  and  destined  for  a DTE,  the  interface  of  which  enters 
the  DTE  CLEAR  REQUEST  state  (p6)  may  be  delivered  before  the 
DCE  CLEAR  CONFIRMATION  packet  is  sent  to  that  DTE.  Hence  it 
is  left  to  che  DTE  to  define  DTE  to  DTE  protocols  able  to  cope 
with  the  various  possible  situations  that  iray  occur. 

3.3.2  Numbering  of  Data  Packets 

Each  data  packet  transmitted  at  the  DTE/DCE  interface  for  each 
direction  of  transmission  in  a virtual  call  or  permanent  virtual 
circuit  is  sequentially  numbered. 

The  sequence  numbering  scheme  of  the  packets  is  performed  modulo 
8.  The  packet  sequence  numbers  cycle  through  the  entire  range 
0 to  7.  As  an  additional  facility,  some  Administrations  will 
provide  a sequence  numbering  scheme  for  packets  being  performed 
modulo  128.  In  this  case,  packet  sequence  numbers  cycle  through 
the  entire  range  0 to  127.  The  modulo,  8 or  128,  is  the  same 
for  both  directions  of  transmission  and  is  common  for  all  logical 
channels  at  the  DTE/DCE  interface. 

.* 
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Only  data  packets  contain  this  sequence  imnber  called  the  packet 
send  sequence  number  P(S) . 

. . • 

The  first  data  packet  to  be  transmitted  across  the  DTE/DCE 
interface  for  a given  direction  of  data  transmission^  after  the 
virtual  call  or  permanent  virtual  circuit  has  been  established* 
has  a packet  send  sequence  number  equal  to  0. 

A P(S)  in  a received  data  packet  not  containing  the  proper 
sequence  number  on  a logical  channel  is  considered  by  the  DCE 
as  a local  procedure  error  (see  Sections  3.4.2  and  4.4.3);  the 
DCE  then  resets  the  virtual  call  or  permanent  virtual  circuit. 

3.3.3  Data  Field  Lenqt)i 

The  standard  maximum  User  Data  Field  length  is  128  octets. 

In  addition*  and  in  conjunction  with  optional  user  facilities* 
other  maximum  data  field  lengths  may  be  offered  by 
Administrations . 

If  an  optional  maximum  data  field  length  is  selected  at 
subscription  it  becomes  the  default  maximum  data  field  length 
'common  to  all  logical  channels  at  the  DTE/DCE  interface.  The 
Administration  may  also  permit  selection  of  a maximum  data  field 
length  on  a per  call  basis  (see  Section  5.1.2). 

Optional  maximum  data  field  lengths  offered  will  be  chosen  by 
each  Administration  from  the  following  list:  16*  32*  64*  256* 

512  and  1024  octets. 

The  data  field  of  data  packets  transmitted  by  a DTE  or  DCE  may 
contain  any  number  of  bits  up  to  the  agreed  maximum. 

If  a DTE  or  DCE  wishes  to  indicate  a sequence  of  more  than  one 
packet*  it  uses  a MOPE  DATA  mark  as  defined  below: 

In  a full  data  packet  a DTE  or  DCE  may  indicate  that  more  data 
is  to  follow  with  a mark  called  MOPE  DATA.  This  indication  has 
the  effect  that  such  a packet  may  be  combined  with  the  subsequent 
data  packet  within  the  network. 

Two  categories  of  data  packets  are  defined: 

a)  Packets  which  do  not  have  the  local 
maximum  data  field  length. 

Category  1 

b)  Packets  having  the  local  maximum  data 
field  legnth  and  no  MOPE  DATA  mark. 

Category  2 Packets  having  the  local  maximum  data 
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field  length  and  a MORE  DATA  nark. 

Category  1 packets  will  not  be  combined  with  subsequent  packets. 

complete  packet  sequence  is  defined  as  being  composed  of 
ither  a single  category  1 packet  or  consecutive  category  2 
packets  and  a category  1 packet.  The  sequence  shall  not  be 
rxreceded  by  a category  2 packet. 

Wh  >n  transmitted  by  a source  DTE,  a complete  packet  sequence 
IS  always  delivered  to  the  destination  DTE  as  a complete  packet 
sequence. 

Thus,  if  the  receiving  end  has  a larger  maximum  data  field 
length  than  the  transmitting  end,  then  packets  within  a complete 
packet  sequence  will  be  combined  within  the  network.  They  will 
be  delivered  in  a complete  packet  sequence  where  each  packet 
nas  the  exact  maximum  data  field  length  and  the  MORE  DATA  mark 
set  to  1 , except  for  the  last  one,  the  User  Data  Field  of  which 
may  have  less  than  the  maximum  length. 

If  the  maximum  data  field  length  is  the  same  at  both  ends,  then 
data  fields  of  data  packets  are  delivered  to  the  receiving  DTE 
exactly  as  they  have  been  received  by  the  network,  except 
possibly  with  one  exception:  if  a full  packet  with  a MORE  DATA 
mark  set  to  1 is  followed  by  an  empty  packet.  Then  the  two 
last  packets  can  be  merged  so  as  to  become  a single  full  packet 
with  the  MORE  DATA  mark  set  to  0. 

If  the  receiving  end  has  a smaller  maximum  data  field  length 
than  the  transmitting  end,  then  packets  will  be  segmented  within 
the  network,  and  the  MORE  DATA  mark  set  by  the  network  as 
described  to  maintain  complete  packet  sequences. 

All  category  1 DATA  packets  received  by  a DTE  will  have  the 
MORE  data  mark  set  to  0. 

If  the  User  Data  Field  in  a data  packet  exceeds  the  locally 
permitted  maximum  field  length  then  the  DCE  will  reset  the 
virtual  call  or  permanent  virtual  circuit  with  the  resetting 
cause  "local  procedure  error". 

3.3.4  gga^jifier  bit 

A packet  sequence  may  be  on  one  of  two  levels.  If  a DTE  wishes 
to  transmit  data  on  more  than  one  level,  it  uses  an  indicator 
called  the  QUALIFIER  bit. 

When  only  one  level  of  data  is  being  transmitted  on  a logical 
channel,  the  QUALIFIER  bit  is  always  set  to  zero.  If  t%#o  levels 
of  data  are  being  transmitted,  the  transmitting  DTE  should  set 
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the  QUALIFIER  bit  in  all  packets  of  a complete  packet  sequence 
to  the  sane  value,  either  zero  or  one.  A Conplete  packet  ' 
sequence,  which  is  transmitted  with  the  QUALIFIER  bit  set  to  ’ 
the  same  value  in  all  packets,  is  delivered  by  the  network  as 
a complete  packet  sequence  with  the  QUALIFIER  bit  set  in  all 
packets  to  the  value  assigned  by  the  transmitting  DTE. 

The  action  of  the  network  when  the  QUALIFIER  bit  is  not  set  to 
the  same  value  by  the  transmitting  DTE  within  a complete  packet 
sequence  is  left  for  further  study. 

Packets  are  numbered  consecutively  regardless  of  their  data 
level. 

Provisional  Recommendation  X.29  gives  an  example  of  the 
procedures  to  be  used  when  the  QUALIFIER  bit  is  set  to  one. 

3.3.5  Interrupt  Procedure 

The  interrupt  procedure  allows  a DTE  to  transmit  data  to  the 
remote  DTE,  without  following  the  flow  control  procedure  applying 
to  data  packets  (see  section  3.4)  . The  interrupt  procedure  can 
only  apply  in  the  FLOW  CONTROL  READY  state  (d1)  within  the  DATA 
TRANSFER  State  (p4) . 

The  interrupt  procedure  has  no  effect  on  the  transfer  and  flow 
control  procedures  applying  to  the  data  packets  on  the  virtual 
call  or  permanent  virtual  circuit. 

To  transmit  an  interrupt,  a DTE  transfers  across  the  DTE/DCE 
interface  a DTE  INTERRUPT  packet.  The  DCE  will  then  confirm 
the  receipt  of  the  interrupt  by  transferring  a DCE  INTERRUPT 
confirmation  packet.  The  DTE  should  not  transmit  further  DTE 
INTERRUPT  packets  until  the  first  one  is  confirmed  with  a DCE 
INTERRUPT  CONFIRMATION  packet. 

The  DCE  indicates  an  interrupt  from  the  remote  DTE  by 
transferring  across  the  DTE/DCE  interface  a DCE  INTERRUPT  packet 
containing  the  same  data  field  as  in  the  DTE  INTERRUPT  packet 
transmitted  by  the  remote  DTE.  The  DTE  will  confirm  the  receipt 
of  the  DCE  INTERRUPT  packet  by  transferring  a DTE  INTERRUPT 
CONFIRMATION  packet. 

The  receipt  of  a DCE  INTERRUPT  CONFIRMATION  packet  indicates 
that  the  interrupt  has  been  confirmed  by  the  remote  DTE  by  means 
of  a DTE  INTERRUPT  CONFIRMATION  packet. 

An  INTERRUPT  packet  is  delivered  at  or  before  the  point  in  the 
stream  of  DATA  packets  at  which  it  was  generated. 


3.4 


PrQceduces  for  Flow  Control 


This  subsection  only  applies  to  the  data  transfer  phase  and 
specifies  the  procedures  covering  flow  control  of  data  packets 
and  reset  on  each  logical  channel  used  for  a virtual  call  or 
a permanent  virtual  circuit. 

For  each  direction  of  data  transmission  on  a virtual  call  or 
permanent  virtual  circuit,  a throughput  class  can  be  identified 
wMch  directly  corresponds  to  the  rate  at  which  packets  can  be 
transmitted.  The  throughput  class  indicates  the  throughput 
that  does  not  need  to  be  exceeded  for  that  direction  of  traffic. 
Details  on  throughput  classes  are  given  in  3.4. 1.3. 

3.4.1  Procedure  for  Flow  Control 

At  the  DTE/DCE  interface  of  a logical  channel  used  for  a virtual 
call  or  permanent  virtual  circuit,  the  transirission  of  data 
packets  is  controlled  separately  for  each  direction  and  is  based 
on  authorizations  from  the  receiver. 

3 . 4 . 1 . 1 Window  Description 

At  the  DTE/DCE  interface  of  a logical  channel  used  for  a virtual 
call  or  permanent  virtual  circuit  and  for  each  direction  of 
data  transmission,  a window  is  defined  as  the  ordered  set  of 
w consecutive  packet  send  sequence  numbers  of  the  data  packets 
authorized  to  cross  the  interface. 

The  lowest  sequence  number  in  the  window  is  referred  to  as  the 
lower  window  edge.  When  a virtual  call  or  permanent  virtual 
circuit  at  the  DTE/DCE  interface  has  just  been  established,  the 
window  related  to  each  direction  of  data  transmission  has  a 
lower  window  edge  equal  to  0. 

The  packet  send  sequence  number  of  the  first  data  packet  not 
authorized  to  cross  the  interface  is  the  value  of  the  lower 
window  edge  plus  W (modulo  8,  or  128  when  extended) . 

In  the  absence  of  an  optional  user  facility,  the  window  size 
W for  each  direction  of  data  transmission  at  a DTE/DCE  interface 
is  common  to  all  the  logical  channels  and  agreed  for  a period 
of  time  between  the  DTE  and  the  Administration.  The  value  of 
W does  not  exceed  7,  or  127  when  extended  (see  section  5.1.2). 

3 . 4 . 1 . 2 Flow  control  Principles 

A number  modulo  8,  or  128  when  extended,  referred  to  as  a packet 
receive  sequence  number  P(R),  conveys  across  the  DTE/DCE 
interface  information  from  the  receiver  for  the  transmission 
of  data  packets.  When  tremsmitted  across  the  DTE/DCE  interface. 
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a P(R)  becomes  the  lower  window  edge.  In  this  way»  additional 
data  packets  may  be  authorized  by  the  receiver  to  cross  the 
DTE/DCE  interface. 

When  the  sequence  number  P(S)  of  the  next  data  packet  to  be 
transmitted  by  the  DTE  is  within  the  window,  the  DCE  will  accept 
this  data  packet.  When  the  sequence  number  P(S)  of  the  next 
data  packet  to  be  transmitted  by  the  DTE  is  outside  of  the 
window,  the  DCE  will  consider  the  receipt  of  this  data  packet 
from  the  DTE  as  a procedure  error  and  will  reset  the  virtual 
call  or  permanent  virtual  circuit.  The  DTE  should  follow  the 
same  procedure. 

When  the  sequence  number  P(S)  of  the  next  packet  to  be 
transmitted  by  the  DCE  is  within  the  window,  the  DCE  is 
authorized  to  transmit  this  data  packet  to  the  DTE.  When  the 
sequence  number  P(S)  of  the  next  data  packet  to  be  transmitted 
by  the  DCE  is  outside  of  the  window,  the  DCE  shall  not  transmit 
a data  packet  to  the  DTE. 

The  packet  receive  sequence  number,  P(R),  is  conveyed  in  data, 
RECEIVE  READY  (RR)  and  RECEIVE  NOT  READY  (RNR)  packets. 

The  value  of  a P(R)  received  by  the  DCE  must  be  within  the  range 
from  the  last  P(R)  received  by  the  DCE  up  to  and  including  the 
packet  send  sequence  number  of  the  next  data  packet  to  be 
transmitted  by  the  DCE.  Otherwise,  the  DCE  will  consider  the 
receipt  of  this  P(R)  as  a procedure  error  and  will  reset  the 
virtual  call  or  permanent  virtual  circuit.  The  DTE  should 
follow  the  same  procedure. 

The  receive  sequence  number  P(R)  is  less  than  or  equal  to  the 
sequence  number  of  the  next  expected  data  packet  and  implies 
that  the  DTE  or  DCE  transmitting  P(R)  has  accepted  a^  least  all 
data  packets  numbered  up  to  and  Including  P(R)*-1. 

The  only  universal  significance  of  a P(R)  value  is  a local 
updating  of  the  window  across  the  packet  level  interface.  The 
P(R)  value  may  be  used  within  some  Administration's  networks 
to  convey  an  end-to-end  acknowledgement. 

3 . 4 . 1 . 3 Throughout  Class 

A throughput  class  for  one  direction  of  transmission  is  an 
indication  of  the  throughput  that  does  rot  need  to  be  exceeded 
on  virtual  calls  or  permanent  virtual  circuits.  Thus,  the 
network  is  asked  to  allocate  such  resources  that  the  throughput 
class  can  normally  be  reached.  However,  due  to  the  statistical 
sharing  of  transmission  and  switching  resources,  it  is  not 
guaranteed  that  the  the  throughput  class  can  he  reached  100* 
of  the  time. 
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Depending  on  the  network  and  the  applicable  conditions  at  the 
considered  moment,  the  effective  throughput  may  exceed  the 
throughput  class. 

The  throughput  class  may  only  be  reached  if  the  following 
conditions  are  met: 

(a)  the  access  data  links  of  both  ends  of  a virtual  call 
or  permanent  virtual  circuit  are  engineered  for  the 
throughput  class; 

(b)  the  receiving  DTE  is  not  flow  controlling  the  DCE  such 
that  the  throughput  class  is  not  reachable;  and 

(c)  the  transmitting  DTE  is  sending  data  packets  which  have 
the  maximum  data  field  length. 

The  throughput  class  is  expressed  in  octets/second;  at  a DTE/DCE 
interface,  a maximum  data  field  length  is  specified  for  a virtual 
call  or  permanent  virtual  circuit,  and  thus  the  throughput  class 
can  be  Interpreted  by  the  DTE  as  the  number  of  full  data 
packets/second  that  the  DTE  does  not  have  a need  to  exceed. 

NOTE:  The  definition  of  throughput  class  in  terms  of  quality 
of  service  is  for  further  study. 

3 . 4 . 1 . 4 DTE  and  DCE  Receive  Ready  IRR)  Packets 

RR  packets  are  used  by  the  DTE  or  DCE  to  indicate  that  it  is 
ready  to  receive  the  W data  packets  within  the  window  starting 
with  P(R),  where  P(R)  is  indicated  in  the  RR  packet. 

3 . 4 . 1 . 5 DTE  and  DCE  Receive  Not  Ready  (RNR1  Packets 

RNR  packets  are  used  by  the  DTE  or  DCE  to  indicate  a temporary 
inability  to  accept  additional  data  packets  for  a given  virtual 
call  or  permanent  virtual  circuit.  A DTE  or  DCE  receiving  an 
RNR  packet  shall  stop  transmitting  data  packets  on  the  indicated 
logical  channel,  but  the  window  is  updated  by  the  P (R)  value 
of  the  RNR  packet.  The  receive  not  ready  situation  indicated 
by  the  transmission  of  RNR  packet  is  cleared  by  the  transmission 
in  the  same  direction  of  an  RR  packet  or  by  a reset  procedure 
being  initiated. 

The  transmission  of  an  RR  after  an  RNR  at  the  packet  level  is 
not  to  be  taken  as  a demand  for  retransmission  of  packets  which 
have  already  been  transmitted  but  still  are  in  the  window 
indicated  in  the  RR. 


13 


3.«.2  Proccaure  for  Reset 

Th«- reset  procedure  is  used  to  re* initialize  the  virtual  call' 
or  peraanent  virtual  circuit  and  in  so  doing  removes  in  each 
direction  all  data  and  interrupt  packets  which  may  be  in  the 
network.  (See  section  3.6).  The  reset  procedure  can  only  apply 
in  the  DATA  TRANSFER  State  of  the  OTE/DCE  interface.  In  any 
other  state  of  the  DTE/DCE  interface,  the  reset  procedure  is 
abandoned.  For  example,  when  a clearing  or  restarting  procedure 
is  initiated,  RESET  REQUEST  and  RESET  INDICATION  packets  can 
be  left  unconfirmed. 

For  flow  control,  there  are  three  states  d1,  d2  and  d3  within 
the  DATA  TRANSFER  State  (p4) . They  are  FLOW  CONTROL  READY  (d1) , 
DTE  RESET  REQUEST  (d2) , and  DCE  RESET  INDICATION  (d3)  as  Shown 
in  the  state  diagram  in  Annex  1,  Figure  17/X.25.  When  entering 
state  p4  the  logical  channel  is  placed  in  state  d1.  Annex  2, 
Table  11/X.25  specifies  actions  taken  by  the  DCE  on  the  receipt 
of  packets  from  the  DTE. 

When  a virtual  call  or  permanent  virtual  circuit  at  the  DTE/DCE 
interface  has  just  been  reset,  the  window  related  to  each 
direction  of  data  transmission  has  a lo%ier  window  edge  equal 
to  0,  and  the  numbering  of  subsequent  data  packets  to  cross  the 
OTE/DCE  Interface  for  that  direction  of  data  transmission  shall 
start  from  0. 

3.4. 2.1  Reset  Request  Packet 

The  DTE  shall  indicate  a request  for  reset  by  transmitting  a 
RESET  REQUEST  packet  specifying  the  logical  channel.  This 
places  the  logical  channel  in  the  DTE  RESET  REQUEST  state  (d2) . 

3. 4. 2. 2 Reset  Indication  Packet 

The  DCE  shall  indicate  a reset  by  transmitting  to  the  DTE  a 
RESET  INDICATION  packet  specifying  the  logical  channel  and  the 
reason  for  the  resetting.  This  places  the  logical  channel  in 
the  DCE  RESET  INDICATKW  state  (d3) . In  this  state,  the  DCE 
will  ignore  data,  interrupt,  RR  and  RNR  packets.  (See  section 
3.7)  . 


3.4. 2. 3  Reset  Collision 

Reset  collision  can  occur  when  a DTE  and  a DCE  simultaneously 
transmit  a RESET  REQUEST  packet  and  a RESET  INDICATION  packet. 

In  such  a case,  the  second  one  of  both  those  packets  crossing 
the  interface  is  considered  as  a reset  confirmation.  This 
places  the  logical  channel  in  the  FLOW  CONTROL  READY  state  (d1) . 


3.(1. 2.4  Reset  confirmation  Packets 


when  the  logical  channel  is  in  the  DTE  RESET  REQUEST  state*  the 
DCE  will  confirm  reset  by  transmitting  to  the  DTE  a DCE  RESET 
CONFIRMATION  packet.  This  places  the  logical  channel  in  the 
FLOW  CONTROL  READY  State  (d1)  . 

The  DCE  RESET  CONFIRMATION  packet  can  only  be  interpreted 
universally  as  having  local  significance*  however  within  some 
Administration's  networks  reset  confirmation  may  have  end  to 
end  significance.  In  all  cases  the  time  spent  in  the  DTE  RESET 
REQUEST  state  (d2)  will  not  exceed  a network  dependent  limit. 

The  limit  will  typically  be  lower  than  3 minutes. 

When  the  logical  channel  is  in  the  DCE  RESET  INDICATION  state* 
the  DTE  will  confirm  reset  by  transmitting  to  the  DCE  a DTE 
RESET  CONFIRMATION  packet.  This  places  the  logical  channel  in 
the  FLOW  CONTROL  READY  State  (d1) . (See  section  3.7). 

3.5  Procedure  for  Restart 

The  restart  procedure  is  used  to  simultaneously  clear  all  the 
virtual  calls  and  reset  all  the  permanent  virtual  circuits  at 
the  CTE/DCE  interface.  (See  section  3.6) . 

Annex  1*  Figure  15/X.25  gives  the  state  diagram  which  defines 
the  logical  relationships  of  events  related  to  the  restart 
procedure. 

Annex  2*  Table  12/X.25  specifies  actions  taken  by  the  DCE  on 
the  receipt  of  packets  from  the  DTE.  Details  of  the  action 
which  should  be  taken  by  the  DTE  are  for  further  study. 

3.5.1  Restart  by  the  DTE 

The  DTE  may  at  any  time  request  a restart  by  transferring  across 
the  DTE/DCE  interface  a RESTART  REQUEST  packet.  The  interface 
for  each  logical  channel  is  then  in  the  DTE  RESTART  REQUEST 
state. 

The  DCE  will  confirm  the  restart  by  transferring  a DCE  RESTART 
CONFIRMATION  packet  placing  the  logical  channels  used  for  virtual 
calls  in  the  READY  state  (pi)*  and  the  logical  channels  used 
for  permanent  virtual  circuits  in  the  FLOW  CONTROL  READY  state 
(d1). 

The  DCE  RESTART  CONFIRMATION  packet  can  only  be  interpreted 
universally  as  having  local  significance.  The  time  spent  in 
the  DTE  RESTART  REQUEST  state  (r2)  will  not  exceed  a network 
dependent  limit. 
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3.5.2 


The  DCE  nay  indicate  a restart  by  transferring  across  the  DTE/DCE 
interface  a RESTART  INDICATION  packet.  The  interface  for  each 
logical  channel  is  then  in  the  DCE  RESTART  INDICATION  state 
<r3) . In  this  state  of  the  DTE/DCE  interface,  the  DCE  will 
ignore  data,  interrupt,  call  set-up  and  clearing,  flow  control 
and  reset  packets. 

The  DTE  will  confirm  the  restart  by  transferring  a DTE  RESTART 
CONFIRMATION  packet  placing  the  logical  channels  used  for  virtual 
calls  in  the  READY  state  (pi) , and  the  logical  channels  used 
for  permanent  virtual  circuits  in  the  FLOW  CONTROL  READY  state 
(d1)  . (See  section  3.7). 

3.5.3  Restart  Collision 


Restart  collision  can  occur  when  a DTE  and  a DCE  simultaneously 
transfer  a RESTART  REQUEST  and  a RESTART  INDICATION  packet. 

Under  this  circumstance,  the  DCE  will  consider  that  the  restart 
is  completed  and  will  not  expect  a DTE  RESTART  CONFIRMATION 
packet,  neither  will  it  transfer  a DCE  RESTART  CONFIRMATION 
packet. 

3.6  Effect  of  Clear.  Reset  and  Restart  Procedures  on  the 
Transfer  of  Packets 

All  data  and  interrupt  packets  generated  hy  a DTE  (or  the 
network)  before  initiation  by  the  DTE  or  the  DCE  of  a clear, 
reset  or  restart  procedure  at  the  local  interface  will  either 
be  delivered  to  the  remote  DTE  before  the  DCE  transmits  the 
corresponding  indication  on  the  remote  interface,  or  discarded 
by  the  network. 

No  data  or  interrupt  packets  generated  by  a DTE  (or  the  network) 
after  the  completion  of  a reset  (or  for  permanent  virtual 
circuits  also  a restart)  procedure  at  the  local  interface  will 
be  delivered  to  the  remote  DTE  before  the  completion  of  the 
corresponding  reset  procedure  at  the  remote  interface. 

When  a DTE  initiates  a clear,  reset  or  restart  procedure  on  its 
local  interface,  all  data  and  interrupt  packets  which  were 
generated  by  the  remote  DTE  (or  the  network)  before  the 
corresponding  indication  is  transmitted  to  the  remote  DTE  will 
be  either  delivered  to  the  initiating  DTE  before  DCE  confirmation 
of  the  initial  clear,  reset  or  restart  request,  or  discarded 
by  the  network. 
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NOTE;  The  maxinuni  number  of  packets  vhich  nay  be  discarded  is 
a function  of  network  end-to-end  delay  and  throughout 
class,  and,  in  general,  has  no  relation  to  the  local 
window  sice.  Provision  of  more  precise  information  is 
for  further  study.  Mi thin  networks  which  convey  end-to- 
end  significance  of  P(R) , the  maximum  number  of  packets 
which  may  be  discarded  in  one  transmission  direction  is 
not  larger  than  the  window  size  at  the  CTE/DCE  interface 
of  the  transmitting  DTE. 

3.7  gataBig^fiC§ 

The  system  parameters  applying  to  section  3 are  for  further 
study.  This  study  should  include  considerations  of  timeouts, 
maximum  numbers  of  retries  and  action  to  be  taken  when  these 
maximum  numbers  are  reached. 

3.8  Effects  of  Levels  1 and  2 on  Level  3 

Changes  of  operational  states  of  level  f and  2 of  the  DTE/DCE 
interface  do  not  implicitly  change  the  state  of  each  logical 
channel  at  level  3.  Such  changes  when  they  occur  are  explicitly 
indicated  at  level  3 by  the  use  of  restart,  clear  or  reset 
procedures  as  appropriate. 

h failure  on  levels  1 and/or  2 is  defined  as  a condition  in 
which  the  DCE  cannot  transmit  and  receive  any  frames  because 
of  abnormal  conditions  caused  by  for  instance  line  fault  between 
DTE  and  DCE. 

When  a failure  on  levels  1 and/or  2 is  detected,  the  DCE  will 
transmit  to  the  remote  end 

(a)  a reset  indicating  Out  of  Order  for  a permanent  virtual 
circuit  and 

(b)  a clear  indicating  Out  of  Order  for  an  existing  virtual 
call. 

During  the  failure,  the  DCE  will  clear  any  incoming  virtual 
calls. 

When  the  failure  is  recovered  on  levels  1 and  2,  the  DCE  will 
send  a RESTART  INDICATION  packet  indicating  Network  Operational 
to  the  local  DTE  and  this  will  result  in  a reset  indicating 
Remote  DTE  Operational  to  be  transmitted  to  the  remote  end  of 
each  permanent  virtual  circuit. 

In  other  out  of  order  conditions  on  level  1 and/or  2,  including 
transmission  of  a DISC  command  by  the  DTE,  the  behavior  of  the 
DCE  is  for  further  study. 
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CIRCUIT  FACILITIES 


4. 1 General 

The  possible  extension  of  packet  formats  by  the  addition  of  new 
fields  is  for  further  study. 

NOTE;  Any  such  field: 

(a)  would  only  be  provided  as  an  addition  following  all 
previously  defined  fields,  and  not  as  an  insertion 
between  any  of  the  previously  defined  fields. 

(b)  would  be  transmitted  to  a DTE  only  when  either  the  DCE 
has  been  informed  that  the  DTE  is  able  to  interpret 
this  field  and  act  upon  it,  or  when  the  DTE  can  ignore 
the  field  without  adversely  affecting  the  operation  of 
the  DCE. 

(c)  would  not  contain  any  information  pertaining  to  a user 
facility  to  which  the  DTE  has  not  subscribed. 

Bits  of  an  octet  are  numbered  8 to  1 where  hit  1 is  the  low 
order  bit  and  is  transmitted  first.  Octets  of  a packet  are 
consecutively  numbered  starting  from  1 and  are  transmitted  in 
this  order. 

4.1.1  General  Format  Identifier 

The  General  Format  Identifier  field  is  a four  bit  binary  coded 
field  which  is  provided  to  indicate  the  general  format  of  the 
rest  of  the  header.  The  General  Format  Identifier  field  is 
located  in  bit  positions  8,  7,  6 and  5,  of  octet  1,  and  bit  5 
is  the  low  order  bit  (see  Table  5/X.25). 

Two  of  the  sixteen  possible  codes  are  used  to  identify  the 
formats  for  the  DTE/DCE  interface  defined  herein,  which  provide 
for  virtual  call  and  permanent  virtual  circuit  facilities.  Two 
other  codes  are  used  to  identify  the  similar  formats  in  the 
case  sequence  numbering  scheme  of  data  packets  is  performed 
modulo  128.  Other  codes  of  the  General  Format  Identifier  are 
unassigned. 

NOTE;  It  is  envisaged  that  unassigned  codes  could  identify 

alternative  packet  formats  associated  with  other  facilities 
or  simplified  access  procedures,  for  example,  datagraun 
facility  or  single  access  DTE  procedures. 


TABLE  5/X.25 


GENERAL  FORMAT  IDENTIFIER 


GENERAL  FORMAT  IDENTIFIER 

Octet  1 
bits 

8 7 6 5 

Data  packets 

Sequence  numbering  scheme 
modulo  8 

X 0 0 1 

Sequence  numbering  scheme 
modulo  126 

X 0 1 0 

Call  set-up  and  clearing* 
flow  control,  interrupt, 
reset  and  restart  packets 

Sequence  numbering  scheme 
modulo  8 

0 0 0 1 

Sequence  numbering  scheme 
modulo  128 

0 0 10 

NOTE;  A bit  which  is  indicated  as  "X"  may  be  set  to  either  "O" 
or  "1"  as  discussed  in  subsequent  sections. 


4.1.2  Logical  Channel  Group  Number 

The  logical  channel  group  number  appears  in  every  packet  except 
in  restart  packets  (see  section  4.5)  in  bit  positions  4,  3,  2 
and  1 of  octet  1. 

This  field  is  binary  coded  auid  bit  1 is  the  low  order  bit  of 
the  Logical  Channel  Group  Number. 

4.1.3  Logical  Channel  Number 

The  logical  channel  number  appears  in  every  packet  except  in 
restart  packets  (see  section  4.5)  in  all  bit  positions  of  octet 
2.  This  field  is  binary  coded  and  bit  1 is  the  low  order  bit 
of  the  Logical  channel  Number. 

NOTE;  Logical  channels  are  numbered  from  0 to  4095  using  12 

bits  made  up  of  the  4 bits  of  the  Logical  Channel  Group 
Number  and  the  6 bits  of  the  Logical  Channel  Number. 

The  numbering  is  binary  coded  using  bit  positions  4 
through  1 of  octet  1 followed  by  bit  positions  8 through 
1 of  octet  2 with  bit  1 of  octet  2 as  the  low  order  bit. 


Each  packet  shall  be  identified  in  the  octet  3 of  the  packet 
according  to  the  following  Table  6/X.25. 


TABLE  6/X.25 


PACKET  TYPE  IDENTIFIER 


PACKET  TYPE 

FROM  DCE  TO  DTE 

FROM  DTE  TO  DCE 

CALL  SET-UP 

AND  CLEARING 

INCOMING  CALL 

CALL  REQUEST 

CALL  CONNECTED 

CALL  ACCEPTED 

CLEAR  INDICATION 

CLEAR  REQUEST 

DCE  CLEAR  CONFIRMATION 

DTE  CLEAR  CONFIRMATION 

DATA  AND  INTERRUPT 

DCE  DATA 

DTE  DATA 

DCE  INTERRUPT 

DTE  INTERRUPT 

DCE  INTERRUPT 

DTE  INTERRUPT 

CONFIRMATION 

CONFIRMATION 

FLOW  CONl'ROL  AND  RESET 

DCE  RR 

DTE  RR 

DCE  RNR 

DTE  RNR 

DTE  REJ* 

RESET  INDICATION 

RESET  REQUEST 

DCE  reset  CONFIRMATION 

DTE  RESET  CONFIRMATION 

DCE  RR  (MODULO  128) * 

DTE  RR  (MODULO  128)* 

DCE  RNR  (MODULO  126)* 

DTE  RNR  (MODULO  128)* 

DTE  REJ  (MODULO  128)* 

RESTART 

RESTART  INDICATION 

RESTART  REQUEST 

DCE  RESTART  CONFIRMATION 

DTE  RESTART  CONFIRMATION 

OCTET  3 
BITS 

8 7 6 5 a 3 2 1 


10  11 
1111 
0 10  0 11 
0 10  111 


0 0 1 0 0 0 1 1 
0 0 1 0 0 1 1 1 


X X X 0 0 0 0 1 
X X X 0 0 1 0 1 
X X X 0 1 0 0 1 
0 0 0 1 1 0 1 1 
0 0 0 1 1 1 1 1 
0 0 0 0 0 0 0 1 
0 0 0 0 0 1 0 1 
0 0 0 0 1 0 0 1 


111110  11 
11111111 


* Not  necessarily  available  on  every  network.  Use  of  the 
DTE  REJ  packet  is  described  in  section  5.1.5. 


NOTE:  A bit  which  is  indicated  as  "X"  may  te  set  to  either  "0 
or  "1"  as  discussed  in  subsequent  sections. 


4.2  Call  5et-Pp  and  clearing  Packets 

4*2.1  call  Bemest  and  Incoininq  Call  Packaf  . 

Figure  1/X.25  illustrates  the  format  of  CiOX  BEQUEST  and  IMC(MIIN6 
CALL  packets. 

Address  Lengths, Field 

octet  4 consists  of  field  length  indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2 and  1 indicate  the  length 
of  the  called  DTE  address  in  semi -octets.  Bits  8«  7*  6 and  5 
indicate  the  length  of  the  calling  DTE  address  in  semi-octets. 
Each  address  length  indicator  is  binary  coded  and  bit  1 or  5 
is  the  low  order  bit  of  the  indicator. 

Address  Field 

octet  5 and  the  following  octets  consist  of  the  called  DTE 
address  when  present,  then  the  calling  DTE  address  when  present. 

Each  digit  of  an  address  is  coded  in  a semi-octet  in  binary 
coded  decimal  with  bit  5 or  1 being  the  low-order  bit  of  the 
digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in 
octet  5 and  consecutive  octets  with  two  digits  per  octet.  In 
each  octet,  the  higher  order  digit  is  coded  in  bits  8,  7,  6 and 

5. 

The  Address  Field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2 and  1 of  the  last 
octet  of  the  field  when  necessary* 

NOTE;  This  field  may  be  used  for  optional  addressing  facilities 
such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  %«ell  as  the  coding  of  those 
facilities  is  for  further  study. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2 and  1 of  the  octet  following  the  Address 
Field  indicate  the  length  of  the  Facility  Field  in  octets.  The 
facility  length  indicator  is  binary  coded  and  bit  1 is  the  low 
order  bit  of  the  indicator. 

Bits  8 and  7 of  this  octet  are  unassigned  and  set  to  0. 
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The  Facility  Field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
REQUEST  and  INCOMING  CALL  packets. 

The  coding  of  this  facility  field  is  defined  in  section  5. 

The  Facility  Field  contains  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However,  this  traximum  does 
not  exceed  62  octets. 

Call  User  Data  Field 

Following  the  Facility  Field,  the  Call  User  Data  Field  may  be 
present  and  has  a maximum  length  of  16  octets. 

The  Call  User  Data  Field,  when  present,  is  comprised  of  t«fo 
fields. 

1.  The  Protocol  Identifier  Field 

2.  The  Call  Data  Field. 

The  Protocol  Identifier  Field  is  used  for  protocol  identification 
purposes,  and  the  Call  Data  Field  contains  user  data.  One 
example  of  usage  and  coding  of  the  Protocol  Identifier  Field 
is  specified  in  Provisional  Recommendation  X.29. 

The  protocol  identifier  Field  is  up  to  four  octets  in  length 
and  the  Call  Data  Field,  when  present,  starts  at  the  beginning 
of  the  fifth  octet  of  the  Call  User  Data  Field. 

Bits  8 and  7 of  the  first  octet  of  the  Protocol  Identifier  Field 
determine  the  use  of  the  rest  of  the  Protocol  Identifier  Field. 

Users  are  cautioned  that  if  these  2 bits  have  any  value  other 
than  11,  the  protocol  thus  identified  may  also  be  implemented 
within  public  data  networks. 

On  the  other  hand,  if  these  two  bits  have  the  value  11,  the 
protocol  thus  identified  is  one  which  public  data  networks  do 
not  implement. 

NOTE;  When  a virtual  call  is  being  established  between  two 

packet  mode  DTE's,  the  network  does  not  act  on  any  part 
of  the  Call  User  Data  Field,  unless  required  to  do 
otherwise  by  an  appropriate  request  for  an  optional  user 
facility  on  a per  call  basis,  such  a facility  is  for 
further  study. 


4.2,2  Call  Accepted  and  Call  Connected  Packets 

Figure  2/X.25  illustrates  the  format  of  CALL  ACCEPTED  and  CAIX 
CONNECTED  packets. 

Address  Lengths  Field 

Octet  4 consists  of  field  length  Indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2 and  1 indicate  the  length 
of  the  called  DTE  address  in  semi-octets.  Bits  8«  7,  6 and  5 
indicate  the  length  of  the  calling  DTE  address  in  semi-octets. 
Each  address  length  indicator  is  binary  coded  and  bit  1 or  5 
is  the  low  order  bit  of  the  indicator. 

Address  Field 

octet  5 and  the  following  octets  consist  of  the  called  DTE 
address  when  present,  then  the  calling  DTE  address  when  present* 

Each  digit  of  an  address  is  coded  in  a semi-octet  in  binary 
coded  decimal  with  bit  5 or  1 being  the  low-order  bit  of  the 
digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in 
octet  5 and  consecutive  octets  with  two  digits  per  octet.  In 
each  octet,  the  higher  order  digit  is  coded  in  bite  8,  7,  6 and 

5. 

The  address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2 and  1 of  the  last 
octet  of  the  field  when  necessary. 

Note:  This  field  may  be  used  for  optional  addressing  facilities 
such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  well  as  the  coding  of  those 
facilities  is  for  further  study. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2 and  1 of  the  octet  following  the  Address 
Field  indicate  the  length  of  the  Facility  Field  in  octets.  The 
facility  length  indicator  is  binary  coded  and  bit  1 is  the  low 
order  bit  of  the  indicator. 

Bits  8 and  7 of  this  octet  are  unassigned  and  set  to  0. 

Eagility  Field 

The  facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
ACCEPTED  and  CALL  CONNECTED  packets. 


The  coding  of  this  facility  field  le  defined  in  section  5. 

The  Facility  Field  cohtaine  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  Bowever,  this  maximum  does 
not  exceed  62  octets. 

4.2.3  Cl^ag_Eeque8t  and  Cleax  Indication  Packets 

Figure  3/X.25  illustrates  the  format  of  CLEAR  REQUEST  and  CLEAR 
INDICATION  packets. 

glfiariDg-C3tfss,ileid 

octet  4 is  the  Clearing  Cause  Field  and  contains  the  reason  for 
the  clearing  of  the  call. 

The  coding  of  the  Clearing  Cause  Field  in  CLEAR  INDICATION 
packets  is  given  in  Table  7/X.25. 

The  bits  of  the  Clearing  Cause  Field  in  CLEAR  REQUEST  packets 
should  be  set  to  0 by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 

Diagnostic  code 

Octet  5 is  the  Diagnostic  Code  and  contains  additional 
information  on  the  reason  for  the  clearing  of  the  call. 

In  a CLEAR  REQUEST  packet,  the  Diagnostic  Code  is  not  mandatory. 

In  a CLEAR  INDICATION  packet,  if  the  Clearing  Cause  Field 
indicates  DTE  Clearing,  the  Diagnostic  Code  is  passed  unchanged 
from  the  clearing  DTE.  If  the  clearing  DTE  has  not  provided 
a Diagnostic  Code  in  its  CLEAR  REQUEST  packet,  then  the  bits 
of  the  Diagnostic  Code  in  the  resulting  CLEAR  INDICATION  packet 
will  all  be  zero. 

When  a CLEAR  INDICATION  packet  results  from  a RESTART  REQUEST 
packet,  the  value  of  the  Diagnostic  Code  will  be  that  specified 
in  the  RESTART  REQUEST  packet,  or  all  zeros  in  the  case  where 
no  Diagnostic  Code  has  been  specified  in  RESTART  REQUEST. 

When  the  Clearing  Cause  Field  does  not  indicate  DTE  Clearing, 
the  bits  of  the  Diagnostic  code  in  a CLEAR  INDICATION  packet 
are  all  set  to  0 when  no  specific  additional  information  for 
the  clearing  is  supplied.  Other  values  are  for  further  study. 


NOTE;  The  contents  of  the  diagnostic  code  field  does  not  alter 
the  meaning  of  the  cause  field.  A DTE  is  not  required 
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to  undertake  any  action  on  the  contents  of  the  diagnostic 
code  field.  Unspecified  code  combinations  in  the 
diagnostic  code  field  shall  not  cause  the  DTE  to  not 
accept  the  cause  field. 


TABLE  7/X.25 

CODING  OF  CLEARING  CAUSE  FIELD  IN  CLEAR  INDICATION  PACKET 


DTE  Clearing 


Number  Busy 

Out  of  Order 

Remote  Procedure  Error 

Reverse  Charging  Not  Subscribed 


Invalid  Call 
Access  Barred 
Local  Procedure  Error 


Network  Congestion 
Not  obtainable 


DTE  Incompatible  Call 


8 7 6 5 4 3 2 1 


00000000 


0 0 0 0 0 0 0 1 
0 0 0 0 1 0 0 1 
0 0 0 1 0 0 0 1 
0 0 0 1 1 0 0 1 


0 0 0 0 0 0 1 1 
0 0 0 0 1 0 1 1 
0 0 0 1 0 0 1 1 


0 0 0 0 0 1 0 1 
0 0 0 0 1 1 0 1 


0 0 1 0 0 0 0 1 


4.2.4  DTE  and  DCE  Clear  Confirmation  Packets 


Figure  4/X.25  illustrates  the  format  of  the  DTE  and  DCE  CLEAR. 


4.3  Data  and  Interrupt  Packets 
4.3.1  DTE  and  DCE  Data  Packets 

Figure  5/X.25  illustrates  the  format  of  the  DTE  and  DCE  DATA 
packets.  ^ 

Qualifier  Bit 

Bit  8 in  octet  1 is  the  QUALIFIER  bit. 


Packet  Receive  Sequence  Number 

Bits  8*  7 and  6 of  octet  3 or  bits  8 through  2 of  octet  4,  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P (B) . P(B)  is  binary  coded  and  bit  6,  or  bit  2 when 
extended,  is  the  low  order  kit. 
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Bit  5 in  octet  3,  or  bit  1 in  octet  4 when  extended,  is  used 
for  MORE  DATA  indication:  0 for  no  more  data  and  1 for  more 
data. 

Packet  Send  sequence  Number 

Bits  4,  3 and  2 of  octet  3,  or  bits  6 through  2 of  octet  3 when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence 
Number  P(S).  P(S)  is  binary  coded  and  bit  2 is  the  low  order 
bit. 

User  Data  Field 

Bits  following  octet  3,  or  octet  4 when  extended,  contain  user 
data. 

4.3.2  DTE  and  DCE  Interrupt  Packets 

Figure  6/X.25  illustrates  the  format  of  the  DTE  and  DCE  INTERRUPT 
packets. 

Interrupt  User  Data  Field 
octet  4 contains  user  data. 

4.3.3  DTE  and  DCE  Interrupt  confirmation  Packets 

Figure  7/X.25  illustrates  the  format  of  the  DTE  and  DCE  INTERRUPT 
CONFIRMATION  packets. 

4.4  Flow  control  and  Beset  Packets 

4.4.1  DTE  and  DCE  Receive  Ready  iPRl  Packets 

Figure  8/X.25  illustrates  the  format  of  the  DTE  and  DCE  RR 
packets. 

Packet  Receive  sequence  Number 

Bits  8,  7 and  6 of  octet  3,  or  bits  8 through  2 of  octet  4 when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  tit  6,  or  bit  2 when 
extended,  is  the  low  order  bit. 

4.4.2  DTE  and  DCE  Receive  Not  Beady  (RNP)  Packets 

Figure  9/X.25  illustrates  the  format  of  the  DTE  and  DCE  RNR 
packets. 
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Packet  Beceive  Sequence  Number 

Bite  8,  7 and  6 of  octet  3«  or  bite  8 through  2 of  octet  8 when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  ie  binary  coded  and  bit  6,  or  bit  2 when 
extended,  in  the  low  order  bit. 

8>4.3  Beset  Request  and  Reset  Indication  Packete 

Figure  IO/X.25  illustrates  the  format  of  the  RESET  REQUEST  and 
RESET  INDICATION  packets. 

Resetting  Cause  Field 

Octet  4 is  the  Resetting  Cause  Field  and  contains  the  reason 
for  the  reset. 

The  coding  of  the  Resetting  Cause  Field  in  a RESET  INDICATION 
packet  is  given  in  Table  8/X.25. 

The  bits  of  the  Resetting  Cause  Field  in  a RESET  REQUEST  packet 
should  be  set  to  0 by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 

Diagnostic  Code 

octet  5 is  the  Diagnostic  Code  and  contains  additional 
information  on  the  reason  for  the  reset. 

In  a RESET  REQUEST  packet  the  Diagnostic  code  is  not  mandatory. 

In  a RESET  INDICATION  packet,  if  the  Resetting  Cause  Field 
indicates  a DTE  Reset,  the  Diagnostic  Code  has  been  passed 
unchanged  from  the  resetting  DTE.  If  the  DTE  requesting  a reset 
has  not  provided  a Diagnostic  Code  in  its  RESET  REQUEST  packet, 
then  the  bits  of  the  Diagnostic  Code  in  the  resulting  RESET 
INDICATION  packet  will  all  be  zeros. 

If  a RESET  INDICATION  packet  results  from  a RESTART  REQUEST 
packet,  the  value  of  the  Diagnostic  Code  will  be  that  specified 
in  the  RESTART  REQUEST,  or  all  zeros  in  the  case  where  no 
Diagnostic  Code  has  been  specified  in  RESTART  REQUEST. 

If  the  Resetting  Cause  Field  does  not  indicate  a DTE  Reset,  the 
bits  of  the  Diagnostic  Code  in  a RESET  INDICATION  packet  are 
all  set  to  0 when  no  specific  additional  information  for  the 
reset  is  supplied,  other  values  are  for  further  study. 


£:  The  contents  of  the  diagnostic  code  field  does  not  alter 
the  meaning  of  the  cause  field.  A DTE  is  not  required 
' to  undertake  any  action  on  the  contents  of  the  diagnostic 
code  field.  Unspecified  code  combinations  in  the 
diagnostic  code  field  shall  not  cause  the  DTE  to  not 
accept  the  cause  field. 

TABLE  8/X.25 

CODING  OF  RESETTING  CAUSE  FIELD  IN  RESET  INDICATION  PACKET 


8 7 6 5 4 3 2 1 


DTE  Reset 


Out  of  Order* 

Remote  Procedure  Error 
Local  Procedure  Error 
Network  Congestion 
Remote  DTE  operational* 
Network  Operational 


0 0 0 0 0 0 0 1 
0 0 0 0 0 0 1 1 
0 0 0 0 0 1 0 1 
0 0 0 0 0 1 1 1 
0 0 0 0 1 0 0 1 
0 0 0 0 1 1 1 1 


* Applicable  to  permanent  virtual  circuits  only. 

4.4.4  DTE  and  DCE  Reset  Confirmation  Packets 

Figure  11/X.25  illustrates  the  format  of  the  DTE  and  DCE  RESET 
CONFIRMATION  packets. 


4.5  Restart  Packets 
4.5.1  Restart  Peaue; 


Indication  Packets 


Figure  12/X.25  illustrates  the  format  of  the  RESTART  REQUEST 
and  RESTART  INDICATION  packets.  Bits  4,  3,  2 and  1 of  the  first 
octet  and  all  bits  of  the  second  octet  are  set  to  0. 

Restarting  Cause  Field 

Octet  4 is  the  Restarting  Cause  Field  and  contains  the  reason 
for  the  restart. 

The  coding  of  the  Restarting  Cause  Field  in  the  RESTART 
INDICATION  packets  is  given  in  Table  9/X.25. 

The  bits  of  the  Restarting  Cause  Field  in  RESTART  REQUEST  packets 
should  be  set  to  0 by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 
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Diagnostic  Code 

octet  '5  is  the  Diagnostic  Code  and  contains  additional 
information  on  the  reason  for  the  restart.  In  a RESTART  REQUEST 
packet^  the  Diagnostic  Code  is  not  mandatory. 

The  Diagnostic  Code,  if  specified,  is  passed  to  the  corresponding 
DTEs  as  the  Diagnostic  Code  of  either  a RESET  INDICATION  packet 
or  a CLEAR  INDICATION  packet  as  appropriate.  The  bits  of  the 
Diagnostic  Code  in  a RESTART  INDICATION  packet  are  all  set  to 
zero  when  no  specific  additional  information  for  the  restart 
is  supplied.  Other  values  are  for  further  study. 


NOTE;  The  contents  of  the  diagnostic  code  field  does  not  alter 
the  meaning  of  the  cause  field.  A DTE  is  not  required 
to  undertake  any  action  on  the  contents  of  the  diagnostic 
code  field.  Unspecified  code  combinations  in  the 
diagnostic  code  field  shall  not  cause  the  DTE  to  not 
accept  the  cause  field. 


TABLE  9/X.25 


CODING  OF  RESTARTING  CAUSE  FIELD  IN  RESTART 
INDICATION  PACKETS 


8 

7 

6 

5 

4 

3 

2 

1 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

0 

0 

0 

1 

1 

1 

Local  Procedure  Error 


Network  Congestion 
Network  operational 


Figure  13/X.25  illustrates  the  format  of  the  DTE  and  DCE  RESTART 
CONFIRMATION  packets.  Bits  4,  3,  2 and  1 of  the  first  octet 
and  all  bits  of  the  second  octet  are  set  to  0. 

4.6  Packets  Reguired  for  Optional  User  Facilities 


Figure  14/X.25  illustrates  the  format  of  the  DTE  REJ  packets, 
used  in  conjunction  with  the  Packet  Retransirission  Facility 
described  in  section  5. 
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Packet  Bgceiye  Sequence  Number 

Bits  8,  1 and  6 of  Octet  3,  or  bits  8 through  2 of  octet  « when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2 when 
extended,  is  the  low  order  bit. 


5.  PROCEDURES  AND  FORMATS  FOR  OPTIONAL  DSER  FACI1ITIE8  TO 
BE  STUDIED  FOR  VIRTUAL  AND  PBRMANENT  VIRTUAL 
CIBCUIT  FACILITIES 


The  following  is  a technical  description  of  procedures  and 
formats  for  user  facilities  which  have  been  proposed  for  study 
for  inclusion  in  Recommendation  X.2,  this  being  for  further 
study. 


NOTE;  However,  the  closed  user  group  facility  is  already 
mentioned  in  Recommendation  X.2. 


5.1  Procedures  for  Optional  User  Facilities 

5.1.1  Reverse  Charging 

Reverse  Charging  is  an  optional  user  facility;  it  can  be 
requested  by  a DTE  for  a given  virtual  call. 

The  reverse  charging  facility  needs  some  indication  in  the  CALL 
REQUEST  and  the  INCOMING  CALL  packets. 

5.1.2  Throughput  Class  Selection  and  Indication 

Throughput  class  selection  and  indication  is  an  optional  user 
facility  agreed  for  a period  of  time  which  can  be  used  by  a DTE 
for  virtual  calls  and  permanent  virtual  circuits. 

In  the  absence  of  the  throughput  class  selection  and  indication 
facility  or  other  related  user  facilities  (these  facilities 
being  for  further  study) , the  throughput  classes  considered  for 
the  call  originated  by  the  DTE  are  those  agreed  bet%«een  the  DTE 
and  the  Administration  as  the  default  values. 

When  the  calling  DTE  has  subscribed  to  the  facility,  it 
separately  Indicates  throughput  classes  applied  to  each  of  the 
two  directions  of  transmission  of  the  virtual  call. 

When  the  called  DTE  has  subscribed  to  the  facility,  the 
throughput  classes  of  both  directions  of  transmission  are 
indicated  to  the  called  DTE  in  the  INCOMING  CALL  packet.  These 
throughput  classes  are  those  defined  by  the  calling  DTE  either 
by  default  or  explicitly. 
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Throughput  classes  give  an  indication  to  the  network  about  the 
level  of  resources  that  need  to  be  allocated  to  the  virtual 
call  or  permanent  virtual  circuit.  They  do  not  necessarily 
have  an  effect  upon  packet  length  and  window  size  locally  used 
at  the  OTE/DCE  interface  (Note  1) . 

When  the  throughput  class  selection  and  indication  facility  is 
used,  the  window  size  and  packet  length  to  be  used  for  each 
direction  of  transmission  are  selected  by  reference  to  tables 
specified  by  the  Administration.  These  tables  are  built  in 
such  a manner  that  they  take  into  account  the  relationship  of 
throughput  class  to  packet  size  and  window  size  in  those  cases 
when  such  a relationship  exists. 

These  tables  are  subject  to  an  agreement  between  the 
Administration  and  the  DTE,  and  must  be  such  that,  in  the 
conditions  of  use  expected  by  the  user,  the  chosen  window  sizes 
and  packet  lengths  effectively  permit  to  reach,  on  the  DTE/DCE 
interface,  each  one  of  the  throughput  classes. 

NOTE  1 ; Dsers  eure  cautioned  that  the  choice  cf  too  small  a 
window  and  packet  size  at  a DTE/DCE  interface  may 
adversely  affect  the  attainable  throughput  class  of 
a virtual  call  or  permanent  virtual  circuit.  This  is 
likewise  true  of  flow  control  mechanisms  adopted  by 
the  DTE  to  control  data  transmission  from  the  DCE. 

NOTE  2:  On  a permanent  virtual  circuit,  no  mechanism  is  provided 
to  dynamically  select  throughput  class  ncr  for  the 
network  to  indicate  throughput  classes. 

5.1.3  Reverse  Charging  Acceptance 

Reverse  Charging  Acceptance  is  an  optional  user  facility  agreed 
for  a period  of  time. 

This  user  facility,  if  subscribed  to,  authorizes  the  DCE  to 
transmit  to  the  DTE  incoming  calls  which  request  the  Reverse 
Charging  facility.  In  the  absence  of  this  facility,  the  DCE 
will  not  transmit  to  the  DTE  incoming  calls  which  request  the 
Reverse  Charging  facility. 

5.1.4  One-Way  Logical  Channel 

One-way  Logical  Channel  is  an  optional  user  facility  agreed  for 
a period  of  time. 

This  is  a user  facility  which  limits  the  use  of  a logical  channel 
to  either  incoming  or  outgoing  calls  (Incoming  or  outgoing 
access  on  logical  channels) . 
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5.1.5  Packet  Retransmission 

Packet  Retransmission  is  an  optional  user  facility  agreed  for' 
a period  of  time. 

This  user  facility  allows  a DTE  to  request  retransmission  of 
one  or  several  consecutive  data  packets  from  the  DCE  by 
transferring  across  the  DTE/DCE  interface  a DTE  REJECT  packet 
specifying  a logical  channel  number  and  a sequence  number  P(P) . 

The  value  of  this  P(R)  should  be  within  the  range  from  the  last 
P(R)  received  by  the  DCE  up  to,  but  not  including,  the  P(S)  of 
the  next  data  packet  to  be  transmitted  by  the  DCE. 

When  receiving  a DTE  REJECT  packet,  the  DCE  initiates  on  the 
specified  logical  channel  retransmission  of  the  data  packets; 
the  Packet  Send  Sequence  Numbers  of  which  are  starting  from 
P(R)  where  P(R)  is  indicated  in  the  DTE  REJECT  packet.  Until 
the  DCE  transfers  across  the  DTE/DCE  interface  a DCE  DATA  packet 
with  a Packet  Send  Sequence  Number  equal  to  the  P(R)  indicated 
in  the  DTE  REJECT  packet,  the  DCE  will  consider  the  receipt  of 
another  DTE  REJECT  packet  as  a procedure  error  and  reset  the 
virtual  call  or  permanent  virtual  circuit. 

Additional  data  packets  pending  initial  transmission  may  follow 
the  retransmitted  data  packet (s) . 

A DTE  receive  not  ready  situation  indicated  by  the  transmission 
of  RNR  packet  is  cleared  by  the  transmission  of  a DTE  REJECT 
packet. 

The  conditions  under  which  the  DCE  ignores  a DTE  REJECT  packet, 

or  considers  it  as  a procedure  error,  are  those  described  for 

flow  control  packets.  | 

5.1.6  Closed  User  Group  Facility 

Closed  User  Group  is  an  optional  user  facility  agreed  for  a 
period  of  time  between  the  Administration  and  a group  of  users. 

This  facility  permits  the  users  of  the  group  to  communicate 
with  each  other,  but  precludes  communication  with  all  other 
users. 

A DTE  may  belong  to  more  th^ul  the  closed  user  group. 

The  calling  DTE  should  specify  the  closed  user  group  selected 
for  a virtual  call  using  the  optional  user  facility  parameters 
in  the  CALL  REQUEST  packet. 
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The  closed  user  group  selected  for  a virtual  call  will  be 
indicated  to  a called  DTE  using  the  optional  user  facility 

parameters  in  the  INCOMING  CALL  packet.  ; 

when  a DTE  only  belongs  to  one  closed  user  group,  this  indication 
may  not  be  present  in  the  CALL  REQUEST  or  INCOMING  CALL  packet. 

5.1.7  Bilaterial  closed  User  Group  Facility 

I ; 

I A Bilateral  Closed  User  Group  facility  is  an  optional  user 

[ facility  which  can  be  used  for  a period  of  time  by  a DTE  for 

t virtual  call.  This  facility  permits  such  users  to  communicate 

\ with  each  other,  but  precludes  communication  with  all  other 

I users. 

I A DTE  may  belong  to  more  than  one  bilateral  clbsed  user  group. 

' rhe  calling  DTE  should  specify  the  bilateral  user  group  selected 

for  a virtual  call  using  the  optional  user  facili<!y  parameter 
in  the  CALL  REQUEST  packet.  The  called  DTE  address  length  shall 
be  coded  all  zeros. 

The  bilateral  closed  user  group  for  a virtual  call  will  be 
indicated  to  a called  DTE  using  the  optional  user  facility 

parameters  in  the  INCOMING  CALL  packet.  | 

i 

5.2  Formats  for  Optional  User  Facilities  ? 

, > 

I 5.2.1  General 

! The  facility  field  is  present  only  when  a DTE  is  using  an 

optional  user  facility  requiring  some  indication  in  the  CALL 
REQUEST  packet  or  the  INCOMING  CALL  packet. 

The  facility  field  contains  one  or  more  facility  elements.  The  ! 

first  octet  of  each  facility  element  contains  a facility  code  ' 

I to  indicate  the  facility  or  facilities  requested. 

NOTEt  The  action  taken  by  the  DCE  when  a facility  code 
appears  more  than  once  is  for  further  study. 

i 

The  facility  codes  are  divided  into  four  classes,  by  making  use 
of  bits  7 and  8 of  the  facility  code  field,  in  order  to  specify 
facility  parameters  consisting  of  1,  2,  3,  or  a variable  number 
of  octets.  The  general  class  coding  is  shown  below. 


Facility  code  field 

bit  87654321 

CLASS  A OOXXXXXX  for  single  octet  paraoeter  field 

CLASS  B 01XXXXXX  for  double  octet  parameter  field 

CLASS  C 10XXXXXX  for  triple  octet  parameter  field 

CLASS  D 11XXXXXX  for  variable  length  parameter  field 

For  class  D the  octet  following  the  facility  code  indicates  the 
lengthy  in  octets,  of  the  facility  parameter  field.  The  facility 
parameter  field  length  is  binary  coded  and  bit  1 is  the  low 
order  bit  of  this  indicator. 


CLASS  A 

8 7 6 5 4 3 2 1 


■■ 

X 

X X X X X 

Facility 

parameter  field 

CLASS  C 

8 7 6 5 4 3 2 1 


1 0 X X X X X X 


Facility 

parameter 

field 


Figure  5.1.  Facility  code  general  formats 

The  facility  code  field  is  binaury  coded  and,  without  extension, 
provides  for  a maximum  of  64  facility  codes  for  classes  A,  B 
and  C and  63  facility  codes  for  class  D giving  a total  of 
255  facility  codes. 

Facility  code  11111111  is  reserved  for  extension  of  the  facility 
code.  The  octet  following  this  octet  indicates  an  extended 


CLASS  B 

8 7 6 5 4 3 2 1 


1 X X X X X X 


Facility  parameter 
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CLASS  D 

8 7 6 5 4 3 2 


1 1 X X X X X X 


1 Facility  parameter 

field  length 
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field 
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facility  code  having  the  fonnat  A«  B,  C Oj.'  D as  defined  above. 
Repetition  of  facility  code  11111111  is  pexvitted  and  thus 
additional  extensions  result. 

The  coding  of  the  facility  parameter  field  is  dependent  on  the 
facility  being  requested. 

A facility  code  may  be  assigned  to  identify  a number  of  specific 
facilities,  each  having  a bit  in  the  parameter  field  indicating 
facility  requested/facility  not  requested.  In  this  situation, 
the  parameter  field  is  binary  encoded  with  each  bit  position 
relating  to  a specific  facility.  A 0 indicates  that  the  facility 
related  to  the  particular  bit  is  not  requested  and  a 1 indicates 
that  the  facility  related  to  the  particular  bit  is  requested. 
Parameter  bit  positions  not  assigned  to  a specific  facility  are 
set  to  zero.  If  none  of  the  facilities  represented  by  the 
facility  code  are  requested  for  a virtual  call,  the  facility 
code  and  its  associated  parameter  field  need  not  be  present. 

A Facility  Marker,  consisting  of  a single  octet  pair,  is  used 
to  separate  requests  for  X.25  facilities,  as  defined  in  this 
section,  from  requests  for  non*X. 25  facilities  that  may  also 
be  offered  by  an  Administration.  The  first  octet  is  a facility 
code  and  is  set  to  zero  and  the  second  octet  is  the  facility 
parameter  field. 

The  coding  of  the  parameter  field  will  be  either  all  zeros  or 
all  ones  depending  on  whether  the  facility  requests  following 
the  marker  refer  to  facilities  offered  by  the  calling  or  called 
network,  respectively.  For  intra-network  virtual  calls,  the 
parameter  field  should  be  all  zeros. 

Requests  for  facilities  offered  by  the  calling  and  called 
networks  may  be  simultaneously  present  within  the  facility  field 
and  in  such  cases  two  Facility  Markers  will  be  required  with 
parameter  fields  coded  as  described  above. 

Within  the  facility  field,  requests  for  X.25  facilities  will 
precede  all  requests  for  non-X.25  facilities  and  Facility  Markers 
need  only  be  included  when  requests  for  non-X.25  facilities  are 
present. 


5.2.2  Coding  of  Facility  Field  for  Particular  Facilities 


5.2. 2.1 


The  coding  of  the  facility  code  and  parameter  fields  for  Reverse 
Charging  is  the  same  in  CALL  REQUEST  and  INCOMING  CALL  packets. 
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The  coding  of  the  facility  code  field  for  Reverse  Charging  is: 
bit:  e 7 6 5 S 3 2 1 
code:  00000001 


The  coding  of  the  facility  parameter  field  is  as  follows: 

bit  1 » 0 for  Reverse  Charging  not  requested 

bit  1 « 1 for  Reverse  Charging  requested 

NOTE:  Bits  8«  7,  6«  5,  4,  3 and  2 could  be  used  for  user 

facilities  other  than  for  Reverse  Charging;  if  not,  they 
are  set  to  0. 

5. 2. 2. 2 Coding  of  Throughput  Class  Selection  and 


The  inclusion  of  facility  code  and  parameter  fields  for 
Throughput  class  Selection  and  Indication  is  optional  to  the 
DTE. 

The  coding  in  INCOMING  CALL  packets  and  in  CALL  REQUEST  packets 
is  the  same. 


The  facility  code  field  for  Throughput  Class  Selection  and 
Indication  is  coded: 

bit;  87654321 

code:  00000010 


The  throughput  class  for  transmission  from  the  calling  DTE  is 
indicated  in  bits  4,  3,  2 and  1.  The  throughput  class  for 
transmission  from  the  called  DTE  is  indicated  in  bits  8,  7,  6 
and  5. 

The  four  bits  indicating  each  throughput  class  are  binary  coded 
and  express  the  logarithm  base  2 of  the  number  of  octets  per 
second  defining  the  throughput  class.  Bit  1 or  5 is  the  low 
order  bit  of  each  throughput  class  indicator. 
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5. 2. 2. 3 Coding  of  Closed  user  Group  Facility  i 

The  coding  of  facility  code  field  and  paraneters  for  Closed  [ 

User  Group  is  the  sane  in  CALL  REQUEST  and  INCOMING  CALL  packets.  : 

Facility  Code  Field  ! 

I 

The  coding  of  the  facility  code  field  for  Closed  User  Groups  i 

is;  ■ 1 


bit  8 7 6 5 4 3 2 1 
code  0000001  1 
Facility. Field 

The  index  to  the  Closed  User  Group  selected  for  the  virtual 
call  is  in  the  form  of  two  decimal  digits.  Each  digit  is  coded 
in  a semi-octet  in  binary  coded  decimal  with  bit  5 being  the 
low  order  bit  of  the  first  digit  and  bit  1 being  the  low  order 
bit  of  the  second  digit. 

Indexes  to  the  same  Closed  User  Group  at  different  DTE/DCE 
interfaces  nay  be  different. 

5.2. 2.4  CQdiDg_Qf_Bilateral  Closed  User  Group  Facility 

The  coding  of  facility  code  field  and  the  format  of  the  facility 
parameter  field  for  Bilateral  Closed  User  Group  are  the  same 
in  CALL  REQUEST  and  INCOMING  CALL  packets. 

Facility  code  Field 

The  coding  of  facility  code  field  for  Bilateral  Closed  User 
Group  is: 


bit;  87654321 
code:  01000001 


Facility , garameter  Field 


The  index  to  the  Bilateral  Closed  User  Group  selected  for  the 
virtual  call  is  in  the  form  of  4 decimal  digits. 


Each  digit  is  coded  in  a semi-octet  in  binary  coded  decimal 
with  bit  5 of  the  first  octet  being  low  order  bit  of  the  first 
digit,  bit  1 of  the  first  octet  being  low  order  bit  of  the 
second  digit,  bit  5 of  the  second  octet  being  low  order  bit  of 
the  third  digit,  and  bit  1 of  the  second  octet  being  low  order 
bit  of  the  fourth  digit. 


Octet 


1*  Octets 


Bits 

8765  >*321 


1 

2 

3 

U 


General 

Format 

Logical  Channel 

Identifier 

See  Note  1 

Group  Number 

Logical 

Channel  Number 

Packet  Type  Identifier 

0 0 

0 0 

10  11 

Calling  DTE  address 

Called  DTE  address 

length 

length 

i 

1 

1 

1 

DTE  Address 

1 

1 

0 0 0 0 

0 0 

Facility  length 

1 

1 

1 

1 

Facilities 

1 

1 

1 

1 

i 

Protocol  Identifier 

I 


t 

Call 

User 

Data 

Field 


Call  Data 


Note  l:  Coded  0001  (modulo  8)  or  0010  (modulo  128). 

Note;  The  figure  assxrnes  that  a single  address  is  present 
consisting  of  an  odd  number  of  digits  (however,  both 
address  fields  may  be  present)  and  that  the  call  user 
data  field  is  an  integral  number  of  octets  greater 
than  I,  in  length. 


Figure  1/X.25  - Call  request  and  incoming  call  packet  format 


40  " 


Bits 

8 7 *6  5 J»'  3 2 1 


Octet  1 
2 
3 

U 

5 

^ Rote:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

This  field  is  not  mandatory  in  CLEAR  REQUEST  packets. 

Figure  3/X.25  - Clear  request  and  clear  indication  packet  format 


General  Format  Logical  Channel 

Identifier  Group  Number 

See  Note 


Logical 

Channel  Number 


Packet  Type  Identifier 

0001  0011 


Clearing  Cause 


Diagnostic  Code 


Bits 


8765  U321 


Octet  1 

General  Format 

Identifier 

See  Note 

Logical  Channel 

Croup  Number 

2 

Logical 

Channel  Number 

3 

Packet  Type  Identifier 

0001  0111 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

Figure  lt/X.25"  clear  confirmation  packet  format 


Octet  1 


Geaeral  Pomat 
Identifier 
0 0 1 


Logical 
Channel  Himber 


3 P(R) 


User  Data 


(Modvilo  8) 


Bits 


Octet  1 


General  Format 
Identifier 
0 10 


Logical 
Channel  Mumi 


User  Data 


(When  extended  to  modulo  128) 


M » More  Data  Indication 
Q * Qualifier  bit 

Note:  The  figure  assumes  that  the  user  data  field  does  not  contain 

an  integral  number  of  octets. 

Figure  5/X.25  -DTE  and  DCE  data  packet  format 


Logical  Channel 
Group  Number 


42 


rarr: 


» 

j 

* 


Bits 

■ 8 7*6  5 3 2 1 

Octet  1 

2 

3 

U 

Figure  6/X.25  “ OTE  and  DCE  interrupt  packet  format 


Octet  1 
2 

3 

Note:  coded  0001  (modulo  8)  or  0010  (modulo  128) 

Figure  7/X.25  " DTE  and  DCE  interrupt  confirmation  packet  format 


Bits 

8765i*321 


General  Format 

Logical  Cheuinel 

Identifier 

See  note 

Group  Number 

1 Logical  n 

1 Channel 

Number  | 

1 Packet  Type  Identifier 

o 

o 

O 

0 111 

General  Format 
Identifier 

See  Note 

Logical  Channel 

Group  Number 

Logical. 

Channel  Number 

0 

Packet  Type  Identifier 

0 1 0 0 0 1 1 

Interrupt  User  Data 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 


Octet  1 


General  Format 
Identifier 
0 0 1 


Logical  Channel 
Group  Number 


Logical 

Channel  N\xaiber 


P(R) 


(Modvtlo  8) 


Bits 

8 7 6 5 3 2 3 

Octet  1 

2 

3 

U 


General  Format 
Identifier 

Q ] 


Logical  Channel 
Group  Niimber 


Logical 

Channel  Humber 


Packet  Type  Identifier 
0 0 0 0 


P{R) 


(when  extended  to  Modulo  128) 


Figure  8/X.25  -DTE  andDCE  HR  packet  format 


3 2 


(Modulo  8) 


Bits 


(when  extended  to  Modulo  128) 


Figure  9/X.25  - DTE  and  DCE  RNB  packet  format 


r 


Bite 

8765»»321 

Octet  1 

General  Format 
Identifier 
[ See  Note 

Logical  Channel 

Group  Number 

2 

Logical 

Channel  Number 

Packet  Type  Identifier 

3 

0 0 0 1 

10  11 

U 

Resetting  Cause 

5 

Diagnostic  Code 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

• This  field  is  not  mandatory  in  RESET  REQUEST  packets. 

Figure  10/X.25  - Reset  request  and  reset  indication  packet  format 


Bits 


8 7 6 5 **  3 2 


Octet  1 

General  Format 
Identifier 

See  Note 

Logical  Channel 

Group  Number 

Logical 

2 

Channel  Number 

Packet  Type  Identifier 

3 

0 0 0 1 

1111 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

Figure  11/X.25  - DTE  and  DCE  reset  confirmation  packet  format 
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Bit* 

5 


1 ■ 

General  Format 

Identifier 

See  Note 

0 0 

0 

0 

2 

0 

0 0 0 

0 0 

0 

0 

3 

1 

Packet  Type  Identifier 
11110 

1 

1 

k 

Restarting  Cause 

5 

Diagnostic  Code* 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

* This  field  is  not  mandatory  in  RESTART  REQUEST  packets 
Figure  12/X.25  - Restart  request  and  restart  indication  packet  format 


Bits 

8 7 6 5 U 3 2 1 


General  Format 

1 

Identifier 

o 

o 

o 

CL 

Octet  1 

See  Note 

2 

0 0 0 0 

0 0 0 0 

3 

Packet  Type 

1111 

Identifier 

1111 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

Figure  13/X.25  ~ DTE  and  DCE  restart  confirmation  packet  format 


Bits 


(When  extended  to  nodulo  128) 


Figure  lU/X.25  - WE  REJ  packet  format 


ANNEX  1 

(to  Recoounendatlon  X.l5) 

PACKET  LEVEL  DTE/DCE  INTERFACE  STATE  DIAGRAMS 
Symbol, definition  of  the  state  dlagrABS 


NOTE  1:  Each  state  is  represented  by  an  ellipse  wherein  the 
state  name  and  number  are  indicated. 

NOTE  2:  Each  state  transition  is  represented  by  an  arrow.  The 
responsibility  for  the  transition  (DTE  or  DCE)  and  the 
packet  it  has  successfully  transmitted  are  indicated 
beside  that  arrow. 


Order  definition  of  the  state  diagrams 


For  the  sake  of  clarity,  the  normal  procedure  at  the  interface 
is  described  in  a number  of  small  state  diagrams.  In  order  to 
describe  the  normal  procedure  fully  it  is  necessary  to  allocate 
a priority  to  the  different  figures  and  to  relate  a higher  order 
diagram  with  a lower  one.  This  has  been  done  by  the  following 
means: 


The  figures  are  arranged  in  order  of  priority  with  Figure 
15/X.25  (Restart)  having  the  highest  priority  and 
subsequent  figures  having  lower  priority.  Priority  means 
that  when  a packet  belonging  to  a higher  order  diagram 
is  transmitted,  that  diagram  is  applicable  and  the  lower 
order  one  is  not. 

The  relation  with  a state  in  a lower  order  diagram  is 
given  by  including  that  state  inside  an  ellipse  in  the 
higher  order  diagram. 


Note  1;  State  pi  for  virtual  calls  or  state  dl  for  permanent  virtual 
circuits . 

Note  2:  This  transition  may  take  place  after  a timeout  in  the  network 
Figure  15/X.25  - Diagram  of  states  for  the  transfer  of  restart  packets 
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Incoming  call 


OTE  Waiting 


OCE  Waiting 


Incoming 


Call  conntctcd 


pS 

Call  coliition 


\ / 

\ conntctad  / 


" S' 

Oau  trantfaf 


Cali  set  up  phase 


Clear  request 


Any  state 


except  p6  or  p7 


Clear  indication 


connected  I 
(see  NotelM 


DTE  Clear 
request 


DCE  Clear  confirnf^tioo 
or  Clear  indication 


indication  l 
(see  Note  3r 


:War 

indication 


DTE  Clear  confirmation 
or  Clear  request 


Jaccepted 
/ (see  Note  21 
or 

Call  Ke- 

OUfeSt 

^Note  4) 


b)  CjII  ciMring  ph«« 


Note  I.  - Tliit  transition  is  possible  only  if  the  previous  state  wai  DTE  Weiting  <p2). 
Note  2.  - This  transition  is  possible  only  if  the  previous  slate  was  DCE  Waiting  (p3). 
Note  3.  - This  transition  may  take  place  after  a timeout  in  the  network. 

Note  4 - This  transitior.  is  pocsible  only  if 
the  previous  state  was  Retdy  (pi) 
or  DCE  V^itlnf  (l>n)* 


Figure  16/X.25  - Diagram  of  states  for  the  transfer  of  call  set-up  and 

call  clearing  packets  within  the  level  3 ready  (rl)  state 
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Flow  control 


confirmition 


confirimtion 


ese  traasitioB*  occur  ooXy  in  the  DATA  TSANCrs  nt 
Note  I.  - Thii  trantition  mtf  Uke  place  after  a time-out  In  the  network. 


Diagram  of  states  for  the  transfer  of  reset  packets 
within  the  data  transfer  (p**)  state 
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NORMAL:  The  action  taken  by  the  DCE  follows  the  procedures  as 
defined  in  section  3. 

ERROR:  The  DCE  discards  the  received  packet  and  indicates  a * 

clearing  by  transmitting  to  the  DTE  a CLEAR  INDICATION 
packet,  with  an  indication  of  Local  Procedure  Error. 

If  connected  through  the  virtual  call,  the  distant  DTE 
is  also  informed  of  the  clearing  by  a CLEAR  INDICATION 
packet,  with  an  indication  of  Remote  Procedure  Error. 

The  coding  of  diagnostic  codes  to  be  used  in  the  ERROR 
procedure  are  listed  in  Table  7bis/X.25. 

It  is  required  that  in  the  absence  of  an  appropriate 
DTE  response  to  a CLEAR  INDICATION  packet  issued  as 
a result  of  an  error  condition  in  state  p6,  the  DCE 
should  eventually  consider  the  DTE/DCE  interface  to 
be  in  the  READY  state  (p1|. 

DISCARD:  The  DCE  discards  the  received  packet  and  takes  no 
subsequent  action  as  a direct  result  of  receiving 
that  packet. 


NOTE  1:  The  actions  taken  by  the  DCE  on  receipt  of  packets 
with  unassigned  logical  channels  are  given  in  Table 
13/X.25. 


NOTE  2:  This  state  does  not  exist  in  the  case  of  an  outgoing 
one-way  logical  channel  (as  perceived  by  the  DTE) . 

NOTE  3:  This  state  does  not  exist  in  the  case  of  an  incoming 
one-way  logical  channel  (as  perceived  by  the  DTE)  • 


NOTE  4:  In  the  case  of  an  incoming  one-way  logical  channel  (as  I 

perceived  by  the  DTE)  the  DCE  will  use  the  ERROR  I 

procedure . 

NOTE  5:  In  the  case  of  an  permanent  virtual  circuit  the  DCE  ] 

discards  the  received  packet  and  indicates  a reset  by 
transmitting  to  the  DTE  a RESET  INDICATION  packet,  •; 

with  an  indication  of  Local  Procedure  Error.  The  I ' 

distant  DTE  is  also  informed  of  the  reset  by  a RESET  ^ 

INDICATION  packet,  with  an  indication  of  Remote  | ' 

Procedure  Error. 


NOTE  6:  This  entry  is  for  further  study.  The  following 
alternatives  have  been  proposed: 

1)  **EPROR  (p7)  note  5";  or 

2)  "See  Table  11/X.25"  - Note  - In  this  case,  the 
following  two  lines  should  be  added  to  Table 
11/X.25. 


I 


Restart  request  or  OTB 
Restart  confirMtion  with  bits 
1 to  t of  octet  1 or  1 to  6 of 
octet  2^0 


low  control 
error 


flow  control 
error 
«13) 


Packets  having  a packet  type  flow  control  flow  control 

identifier  which  is  shorter  than  error  error 

one  octet  or  is  incompatible  with  (d3)  (d3) 

the  ones  defined  in  section  4/X.25 


discard 

(d3) 


discard 

(d3) 


NORMAL:  The  action  taken  tv  the  DCE  follows  the  procedures 

as  defined  in  section  3» 

FLOW 

CONTROL 

ERROR:  The  DCE  discards  the  received  packet  and  indicates 

a reset  by  transmitting  to  the  DTE  a RESET  INDICATION 
packet,  with  an  indication  of  Local  Procedure  Error. 

The  distant  DTE  is  also  informed  of  the  reset  by  a 
RESET  INDICATION  packet,  with  an  indication  of  Remote 
Procedure  Error. 

If  a RESET  INDICATION  is  issued  as  a result  of  a flow 
control  error  condition  in  state  d2  for  permanent  . ^ 

virtual  circuits,  the  DCE  should  eventually  consider  I I 

the  DTE/DCE  interface  to  be  in  the  FLOW  CONTROL  READY  I h 

state  (d1).  In  this  case  the  action  to  be  taken  on 
a virtual  call  is  for  further  study. 

DISCARD:  The  DCE  discards  the  received  packet  and  takes  no 
subsequent  action  as  a direct  result  of  receiving 
that  packet. 

NOTE  1:  The  actions  taken  by  the  DCE  on  receipt  of  packets 

with  unassigned  logical  channels  are  given  in  Table 
13/X.25. 

NOTE  2:  The  DCE  will  consider  the  receipt  of  a DTE  INTERRUPT 

CONFIRMATION  packet  which  does  not  correspond  to  a 
yet  unconfirmed  DCE  INTERRUPT  packet  as  a flow  control 
error  and  will  reset  the  virtual  call  or  permanent 
virtual  circuit.  The  DCE  will  either  discard  or 
consider  as  a flow  control  error  a DTE  INTERRUPT 
packet  received  before  a previous  DTE  INTERRUPT  packet 
has  been  confirmed. 


Action  taken  Yay  the  DCE  on  receipt  of  packets  in  a given  state  of  the  packet  level  DTE/DCI  • 
Interface  as  perceived  by  the  DCE;  restart  procedure  for  assigned  Inplnai  rhAnnoia  (Hote  1) 


57 


NORMAL:  The  action  taken  hy  the  DCE  follows  the  procedures 

as  defined  in  Section  3. 


ERROR:'  The  DCE  discaurds  the  received  packet  and  indicates 
a restarting  by  transmitting  to  the  DTE  a RESTART 
INDICATION  packet,  with  an  indication  of  Local 
Procedure  Error.  If  connected  through  the  virtual 
call,  the  distant  DTE  is  also  informed  of  the 
restarting  by  a CLEAR  INDICATION  packet,  with  an 
indication  of  Remote  Procedure  Error.  In  the  case 
of  a permanent  virtual  circuit,  the  distant  DTE  will 
be  informed  by  a RESET  INDICATION  packet,  with  an 
indication  of  Remote  procedure  Error. 

If  a RESTART  INDICATION  is  issued  as  a result  of  an 
error  condition  in  state  r2,  the  DCE  should  eventually 
consider  the  DTE/DCE  interface  to  be  in  the  LEVEL  3 
READY  State  (r1). 

DISCARD:  The  DCE  discards  the  received  packet  and  takes  no 
subsequent  action  as  a direct  result  of  receiving 
that  packet. 

NOTE  1:  The  actions  taken  by  the  DCE  on  receipt  of  packets 

with  unassigned  logical  channels  are  given  in  Table 
13/X.25. 

NOTE  2:  pi  for  logical  channels  assigned  to  virtual  calls; 

d1  for  logical  channels  assigned  to  permanent  virtual 
circuits. 

NOTE  3:  The  DCE  reaction  to  such  packets  received  during 

states  R1  and  R2  is  independent  of  any  irregularities 
(eg  format  errors)  that  may  exist  in  the  packet 
structure. 


1 


TABLE  13/X.23 
elal  Cases 


DISCARD:  The  DCE  discards  the  received  packet  and  takes  no  subsequent 
action  as  a direct  result  of  receiving  that  packet. 


Packet  from 
the  DTE 

Any  state 

ANY  PACKET  WITH 
UNASSICHIED 

LOGICAL  CHANNEL 

DISCARD 

ANY  PACKET  WITH 

PACKET  LENGTH 
< 2 OCTETS 

DISCARD 

ANY  PACKET  WITH 
INCORRECT  GENERAL 

FORMAT  IDENTIFIER 

DISCARD 

